Seeking help understanding when to use static methods

Question

2.00/5 (1 vote)

See more:

I have read so many conflicting opinions on the use of static methods that my head hurts. Consider the following:

In most of my CRUD applications I use a SqlDataHandler class to handle the interactions with the database for a class (or in some cases group of classes). See below:

C#

public abstract SqlDataHandler
{
    #region Properties
    protected static string ConnectionString { get; set; }
    #endregion

    #region Methods
    protected static DataTable GetDataTable(SqlCommand GetTableCommand)
    {
    	...
    }
    #endregion	
}

public AccountSqlDataHandler : SqlDataHandler
{
    #region Methods
    public static DataTable GetAccountHistory()
    {
    	SqlCommand getAccountHistoryCommand;
    	
    	...
    	
    	return AccountSqlDataHandler.GetDataTable(getAccountHistoryCommand);
    }
    #endregion
    
    #region Ctors
    static AccountSqlDataHandler()
    {
    	AccountSqlDataHandler.ConnectionString = "Connection string for account database";
    }
    #endregion
}

public Account
{
    #region Properties
    public List<HistoryItem> AccountHistory
    {
    	get
    	{
    		List<HistoryItem> accountHistory;
    		
    		accountHistory = this.getItemsFromDataTable(AccountSqlDataHandler.GetAccountHistory());
    		
    		return accountHistory;
    	}
    }
    #endregion
}

As I see it if I use member methods, then either I have to create an AccountSqlDataHandler instance each time, or create an AccountSqlDataHandler member in the Account class. I don't see any advantage to doing this, but from what I'm reading there is an advantage. I would like to understand what it is before I blindly change my methodology.

Posted 16-Jul-13 5:06am

jemaritn80

Updated 16-Jul-13 6:56am

v4

Add a Solution

Comments

[no name] 16-Jul-13 11:15am

http://msdn.microsoft.com/en-us/library/79b3xss3(v=VS.80).aspx[^]

jemaritn80 16-Jul-13 11:21am

I've read that, but I'm not sure I understand. Are you saying this is an appropriate use of a static member, since the users authentication status is the same regardless of the state of the Database object?

Sergey Alexandrovich Kryukov 16-Jul-13 13:04pm

Do you really understand how static method work, in comparison to instance methods? You need to design code by yourself based on this understanding, instead of seeking for ready-to-use approach.
—SA

Maciej Los 16-Jul-13 13:32pm

It's an answer!
My virtual 5!

jemaritn80 16-Jul-13 13:34pm

I disagree. The question is not, "What is the best way to do this?" The question is, "Why is this way not the preferred way?" That question has not been answered.

Maciej Los 16-Jul-13 13:53pm

I'm not saying that is complete answer, but it seems to showing a way... The understanding the difference between static methods and instance methods is the key to good programming ;)
There's not exists prefered way. The same things programmers can achieve in different ways, but the skeleton/framework is the same. Do you now what i mean now?
[EDIT]
Please, follow the ThePhantomUpvoter's link ;)

Sergey Alexandrovich Kryukov 16-Jul-13 14:15pm

Exactly. (And sometime this is a key to having some solution, as opposed to having none :-.)
—SA

jemaritn80 16-Jul-13 15:12pm

But reading up on the issue, there does seem to be a preferred way. The reasons against static methods range from "a loss of generality and reusability" (which I don't see in cases such as mine) all the way to "every time a programmer uses a static method a baby fairy dies." In seriousness, though I am curious why instance methods would be better in my scenario.

Sergey Alexandrovich Kryukov 16-Jul-13 14:13pm

I only said what I said, not stating the that the question is answered or not. I'm trying to see if you understand the fundamental aspect of this problem, before going to specific detail. So, with what do you disagree?
—SA

jemaritn80 16-Jul-13 14:17pm

I'm not disagreeing with you, I was disagreeing with Maciej that the question had been answered. I appreciate you taking the time to get the facts before going further. My response to is below. In essence, yes I do understand static vs. instance methods, but I'm not sure the disadvantages of my design. On StackOverflow it was suggested that this should be a singleton class, but again I'm not sure what the advantage of that would be.

Sergey Alexandrovich Kryukov 16-Jul-13 14:24pm

Okay, than you for the clarification...
—SA

Maciej Los 16-Jul-13 14:30pm

Please, don't get my comment to Sergey's comment so seriously... ;)

Sergey Alexandrovich Kryukov 16-Jul-13 14:14pm

Thank you, Maciej. :-)
—SA

Maciej Los 16-Jul-13 14:34pm

You're welcome ;)

jemaritn80 16-Jul-13 13:20pm

Thank you. I do understand the difference between the two. The code I wrote above is syntactically correct which I believe demonstrates at least a rudimentary understanding. But I am interested in understand the design principles of OOP better. I believe if I could learn why the above sample is not preferred, it would strengthen not only my knowledge but my understanding of these principles.

Sergey Alexandrovich Kryukov 16-Jul-13 14:23pm

Good. Still, the principles come from these basics + some logic. (I would also note that it has little to do with "real" OOP, which basically starts where late binding is introduced, and, in more modern flavors or OOP, interfaces and implementation, and polymorphism. You are still don't do anything truly object-oriented).

By some apparent reasons, it's best to avoid any static data members. They are only used in quite rare situations, if we are talking about good programming techniques. Static data also presents the burden to threading. In contrast to that, static methods should be used extensively. No access to the instance used? A method has to be static, and a failure to do it static is a performance leak (will be detected by FxCop). But having access through static data is even worse. I would prefer talking about "stack methods", those static methods which use stack only. This is a way to go: a method should be either stack or an instance one.

—SA

Maciej Los 16-Jul-13 14:35pm

That's the point!

jemaritn80 17-Jul-13 8:19am

Thanks, SA!

Sergey Alexandrovich Kryukov 17-Jul-13 10:36am

You are welcome.
—SA

[no name] 16-Jul-13 17:27pm

you need use static method when the method is not dependents to class members OR no any other instance would call(change the state) of another instance by calling a method, for example Thread.sleep() is static because no any thread would sleep another thread, so when you call it, it sleeps the called thread. many other reason, you would find them in patterns too :)

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Bernhard Hiller · Accepted Answer · 2013-07-16T21:51:00

When I started working with VB6, I favored "modules" over "classes", and that's somehow similar, with modules corresponding to "static". The paradigm shift to classes took me some time. An important point was that I can have multiple instances of a class which do not interfere with each other: with "static", there exists only one single item in your whole application - and when you need that one item for two different purposes (in your example: you need to handle two different account histories in your application at the same time), then you'll get into trouble. At a first glance, that may not look like a really big issue, but with growing experience, you'll change the paradigm. We can try to explain, but in the end the enlightenment cannot be brought to you by others, it must come into existence within you.

Seeking help understanding when to use static methods

1 solution

Solution 1

Add your solution here

Preview 0

Seeking help understanding when to use static methods

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us