Static members or not?

[robertfah]

We've got a project that used several classes and I wanted to know when is it appropriate to use Static methods within that class? For instance, we have a class called Users. It has properties and methods that hold user information along with add/edit/delete functions as well. But we also have "smaller" classes like Statuses, which all it does is add, edit, delete Statuses. I think it's overkill to have to create an object just to add a status evertime:

Statuses oStatus = new Statuses()

oStatus.AddNewStatus(params)

so I was thinking of making those Static instead. But really didn't know if it's appropriate or correct to do so.

Thoughts?

 

[Rhys666]

Firstly, is the Statuses class a collection class? If it is, all good and well, if it's not then I would suggest rethinking the name and changing it from a plural.

Other than that, think about it more conceptually. 'Add' implies the addition of one thing, ('X'), to another, ('Y'), thus you must have 'Y' to add 'X' to it. However, if the method isn't really functionally going to 'add' but 'Create'you conceptually don't really need 'Y'.

I would probably take a step back and potentially look at adding a static 'Create' method on the Statuses class returning an object of the approriate type, or void dependant on usage.

Rhys

"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it"
Terry Pratchett

 

[jmeckley]

marking a class/method as static isn't about key strokes, or pretty code. it's an architectural decision.

non-static methods are assigned to the class where static methods are assigned to the type. non-static objects handle object state while static members shouldn't (if they do you will all kinds of problems with multi-user/requests). static statefulness also has problems with cross threading issues.

static methods an a scope of the life of the application. non-static classes/methods have scope to the life of the object, which you get to control.

usually there are very few static classes/methods within an application simply because they are not needed.

then there is issue of testability. it's much easier to test member instances rather than static members. I'm talking about automated testing, not manual testing.

so all that said, there is no value in making the object static just to reduce key strokes. it's the wrong reason to make a class static.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[robertfah]

Thanks for all the responses. I know I came off in my question as if the only reason I wanted to change our classes was to save keystrokes, but it's not. Both answers gave me a better understanding of static members and why/when to use them (I think).

Here's my scenario:
We have an asset tracking program that runs over the network. As stated before, it has several classes and only 1 of those (the Users class) is used to retain/update information throughout the life of the application. All other classes are there for DB changes (Add, edit, delete) and some constants (messages, etc.). During the program, we only create a new instance of the "Users" object and update it throughout the program. Other than that, to make calls to the DB, it's simply:

Statuses oStatus = new Status();
oStatus.AddNewStatus("My New Status");

I didn't know if it was more feasible (CPU, memory, etc) to use Static members so that the program wouldn't have to create an object every time (I know .NET handles garbage collection but again, just wanted to be sure).

So I believe it's safe to say that as long as the class that I'm looking to create won't be used to hold data for the life of the application, then it's ok to make them Static? If I'm way off here, please let me know. I'm just trying to get a better understanding of this.

Thanks again for the help, much appreciated.

 

[jmeckley]

as for memory consumption:
creating and destroying objects isn't where memory or performance is a problem.

if the object doesn't hold state then making it static is an option, if it's used throughout the life of the application then it may make sense to make it static, but then again does it provide value? usually there isn't value in static modifiers. Not that it hurts. It just isn't required.

another approach is to design objects for instances and then have another object manage the scope of the object. This is very common of IoC containers. the container framework manages the scope of the object. the object itself (in this case the user repository) has no idea it will be a singleton in the application. that's what the container would control.

Jason Meckley
Programmer

faq855-7190
faq732-7259