[Mercurial]

Static variables. I usually use them as an ObjectCounter, but is it wrong to use them for other purposes, if we're absolutely sure we will have only one instance of that class? I mean, are there any downsides of using static variables? People sometimes go about "don't use static variables for < something > since you're not sure you'll have only one instance of that class". Reading things like that over and over again made me a bit hesitant, so I always try to find another solution even though making something static would make my life easier.

I hope I got the forum right, it's more of Java help than an actual discussion.

[Luckless]

anytime you need a variable to be used by all instances of a class, you use a static variable. For example, what if you need to count how many instances of a certain object you have? you would put a static counter variable in the said class and increment it by one in the constructor. Every time a new instance is created in your main method, the constructor increments the variable.

Another time to use static is if there will be some sort of variable that is the same in all instances, like some sort of calculations. This way, you only have one static variable used by all classes instead of many instance variables with the same value.

If you need a counter for each instance of the class, such as an internal counter, it's better to use a non-static counter so that it is unique to that instance of the class. There aren't downsides to using static variable, only wrong situations

[macosxnerd101]

Static variables are more like the laws of a country. They apply to all citizens (instances of a class). Whereas instance variables are more like people's incomes. They can be the same, but they don't have to be. So for attributes that are Object-specific, you should use instance variables. However, for attributes that apply to all instances of the class or aren't associated with a specific Object (ie., constants), you should use instance static variables.

This post has been edited by macosxnerd101: 23 August 2010 - 07:40 AM
Reason for edit:: Thanks Mercurial for catching the typo!

[baavgai]

The biggest issue with static is that it's kind of the antitheses of Object Oriented. A object has state, a static or class variable is just a global, which is double bad.

If you're looking to do globals, don't. If you must do globals, look into the Singleton Design Pattern.

Beyond an object counter, as you mentioned, constants, and the required main entry point, static is usually just a crutch. Even a counter is better done through some kind of factory pattern.

[cfoley]

Quote

"don't use static variables for < something > since you're not sure you'll have only one instance of that class". Reading things like that over and over again made me a bit hesitant, so I always try to find another solution even though making something static would make my life easier.

There is a design pattern called singleton, which ensures you can only ever create one instance of a particular class. One of its beauties is that it's easy to change your mind and edit a couple of lines to make multiple instances possible. I've lost count of the number of times I've had to do that. Between an initial poor design and changing requirements, you never really know which code is bulletproof and which code is going to have to be redone again and again. It's best to program defensively to make changing your code less of a headache.

If you have constants (that is values which apply to every instance of the class and can never be changed) then static variables are a good choice. Otherwise there are very few times where a static variable is a good thing. If you think it makes your life easier then you are probably not using an object orientated design. To this end, perhaps you could provide an example which you consider easier as a static variable, and if there is a more OO way of doing it, I'll post my suggestion.

Edit: I believe I have just been ninjaed.

This post has been edited by cfoley: 23 August 2010 - 07:21 AM

[Luckless]

macosxnerd101, on 23 August 2010 - 06:07 AM, said:

Static variables are more like the laws of a country. They apply to all citizens (instances of a class). Whereas instance variables are more like people's incomes. They can be the same, but they don't have to be.

Likin' the artsy analogy +1

[Mercurial]

macosxnerd101, on 23 August 2010 - 06:07 AM, said:

However, for attributes that apply to all instances of the class or aren't associated with a specific Object (ie., constants), you should use instance variables.

Or static?

[macosxnerd101]

Fixed. Thanks for catching the typo.

[Mercurial]

macosxnerd101, on 23 August 2010 - 06:41 AM, said:

Fixed. Thanks for catching the typo.

Just to make sure someone else doesn't get it wrong.

cfoley, on 23 August 2010 - 06:20 AM, said:

If you think it makes your life easier then you are probably not using an object orientated design. To this end, perhaps you could provide an example which you consider easier as a static variable, and if there is a more OO way of doing it, I'll post my suggestion.

I am, but I still consider myself a Java beginner (started in Feb). I've learned about OOP concepts, and sometimes I find it hard to implement them since I come from a C background. I realized I can make most things work (like I did in C), but the point is to stick to OOP concepts. So when I wouldn't know how to implement something, I'd make it static just to make it work so I can focus on other stuff and deal with it later (it makes a big mess outta your code, I'm tellin' ya). Nowdays I try to do it the right way, which can be a problem mostly because of my lack of experience.

In other words, using static to make it work is a no-no. Well, define 'make it work'...

[macosxnerd101]

Making it work: Writing modular, reusable code with good OO practices as if the person maintaining it is a serial killer who knows your address. He's really not a person you want your code to frustrate.

In other words, get it working vs. get it working the right way.

If you aren't getting the OO concepts, you should read up on them with some of the tutorials in the Java and Software Development Tutorials sections.

[baavgai]

Mercurial, on 23 August 2010 - 08:55 AM, said:

In other words, using static to make it work is a no-no. Well, define 'make it work'...

Using static. Cut and paste code. Doing something you know is a hack just to get it done. Saying "I'll fix that later" and moving on. Basically, craft versus cobble.

Honestly, beyond the entry point, static is probably one of the most abused elements of Java. It allows procedural ( C ) programmers to fake it. I don't believe it should ever be taught to beginners, because it can rise to the level of evil goto does.

Every language has different ways of getting the job done. A competent programmer should find the most natural way to accomplish a task in a given environment, rather than dragging baggage over from some other environment.

I like C. I admire it's simplicity. I do things in C I wouldn't do anywhere else, like a static global in a source file. Because, in the context of C, that's a singleton for that object code. C pulls that kind of stuff all the time. You don't actually need header files in C projects, though your really should. I use macros and defines all over the place in C. These are things that are terrible practices in most other languages, but good for C.

Know your language. Work with it, not against it.

[Mercurial]

macosxnerd101, on 23 August 2010 - 07:00 AM, said:

Making it work: Writing modular, reusable code with good OO practices as if the person maintaining it is a serial killer who knows your address. He's really not a person you want your code to frustrate.

Perfect

baavgai, on 23 August 2010 - 07:26 AM, said:

Mercurial, on 23 August 2010 - 08:55 AM, said:

In other words, using static to make it work is a no-no. Well, define 'make it work'...

Using static. Cut and paste code. Doing something you know is a hack just to get it done. Saying "I'll fix that later" and moving on. Basically, craft versus cobble.

I must admit your posts are very instructive(mostly 'from my experience' rather than 'here are the facts'), even though I didn't quite understand the bolded parts.

[KYA]

Compare it to a harder science or discipline. If you're constructing a building and you have an issue in one of the corners, you could rework your design to accommodate and account for this error OR you could do just enough to ensure the thing won't fall down, i.e. half-assery.

[macosxnerd101]

I think what baavgai is trying to say is to that using static to make things work is a duct tape and superglue solution, rather than just building things correctly the first time.

[baavgai]

macosxnerd101, on 23 August 2010 - 09:44 AM, said:

I think what baavgai is trying to say is to that using static to make things work is a duct tape and superglue solution, rather than just building things correctly the first time.

Yep, that's the meaning of it.

Your question was, "define 'make it work'..." Make it work can also be, "just get it done, doesn't really matter if it's crooked, no one is going to see that part."

Using static is often done when the programmer can't visualize a viable OO approach. Cut and paste is used when the programmer is too damn lazy to refactor their cut and pasting into a proper method abstraction.

Craft means that programming isn't strictly assembling parts. The is no single "correct" solution for any given programming problem; the permutations of possible solutions for anything non trivial approach infinity. Rather, an experienced programmer can gage the level of knowledge, and competence, of another by looking at their code.

When you take pride in your work, you don't want to leave it unfinished, or shoddily constructed, even if you can. Even if no one else will know. That's craft.