Jump to content
  • Advertisement
Sign in to follow this  
sliders_alpha

Static is evil, supposedly

This topic is 2254 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

So i'm a student in information systems, or to put it more simply java based website for corporation.
Recently I've taken quite some interest in making a minecraft clone, because I like learning new stuff and I want a better minecraft.

I'm working on the graphical engine and I noticed that using a static class containing

  • view distance
  • Sector size
  • installation paths
  • an array of Texture (slick object)

    Could be really usefull, instead of having to pass down and down those data.

    Now, what do you think? is this a good idea to do this? in my line of work static attributes or classes are considered as evil.
    It messes up with our unit testing and mocking.

    As my teacher say, if you want to do static classes go back to procedural languages, you are doing objects now.

    But this is not a information system, so does these rules still apply?

    thanks.

Share this post


Link to post
Share on other sites
Advertisement
Again this is Java. Static objects have their place, but generally it is useful for constants that get shared. It can be useful to have utility functions. But it is less useful for the information you described.

As you point out, it messes up several things to have data in a static object.

You can have multiple views with their own view distance, why not have that part of that class? You can have multiple sectors, why not have that as part of your current sector's information? Etc. All of that information seems to be encapsulated in objects already. You'd need a pretty big strong argument to lose that natural encapsulation and instead put that in a static value.


As for your choice to use it or not, no code base is perfect. Your job is to create a product. Sometimes you need to make difficult choices or use less desirable practices to get things done. Just keep in mind you are trading out a good code practice in exchange for potentially easier code and for less encapsulated access. It is a choice to make, make it intentionally.

Share this post


Link to post
Share on other sites
But obviously, those reasons are not convincing enough. Also, he has found ways in which static is useful. Therefore, saying, "static is evil" doesn't really help see the error of his ways (assuming there are any to begin with) or provide any useful and enlightening info to OP.

With that said, frob gave some good advice. Personally, unless it's a utility method (ex: open a file) or something to be seen and shared by all instances of that class, I would write it the normal object-oriented way. Or as you put it, pass the data down.

And for the record, only "goto is evil" when dealing with C++ and more modern languages. :) Edited by Alpha_ProgDes

Share this post


Link to post
Share on other sites

And for the record, only "goto is evil" when dealing with C++ and more modern languages. :)



Singletons.


[/flamebait]



On topic: I agree with frob entirely. If you find that doing things a certain way makes your code awkward or less than ideal somehow, listen to your instincts, and stop doing that. In particular, cramming a lot of data into a "god static class" is basically the same sin as cramming twenty unrelated pieces of functionality into a single regular class. Put your data near where it is used.

Share this post


Link to post
Share on other sites
static is basically globals.

I rarely make static variables. Static methods, however, are useful.

Share this post


Link to post
Share on other sites
Nothing is inherently evil, these language features exist for a reason. It all depends on what your goals and priorities are.

As a general rule, I would avoid using static variables like that because it essentiall imposes limits on your code, and has the potential to create hard to find bugs if you don't understand the semantics of when and how static objects are created and destroyed - as few people do. If you want a clean design that doesn't box you into a corner, then stay away from statics for your data.

But if you just want to get something done quickly without burning a lot of brain cells on architecture, and using a class with a bunch of static variables gets the job done, go for it. You're not going to go to hell for it ;) Edited by krippy2k8

Share this post


Link to post
Share on other sites
"~=" denotes 'approximately':

static class ~= global instance of non-static class ~= #include ~= using ~= DLLImport

All of those give one or more functions another namespace. Clearly, none of those are inherently evil. In fact, they are all very useful. Edited by EJH

Share this post


Link to post
Share on other sites
There is nothing inherently evil about statics or globals. What is evil about them is letting static or global variables be changed anywhere in the code. The reason people run into problem is because they allow them to be changed anywhere. This leads to a debugging nightmare. If you have a bug you have no idea where it is coming from. So, allow the static to be read from anywhere, but only changed from one location and you will be fine.

I don't use statics that often or globals but there are times in which it is more effective and easier to read if you do.

Share this post


Link to post
Share on other sites

There is nothing inherently evil about statics or globals. What is evil about them is letting static or global variables be changed anywhere in the code. The reason people run into problem is because they allow them to be changed anywhere. This leads to a debugging nightmare. If you have a bug you have no idea where it is coming from. So, allow the static to be read from anywhere, but only changed from one location and you will be fine.

I don't use statics that often or globals but there are times in which it is more effective and easier to read if you do.
That's one problem with global scope.

Another is that having global state means you can't have to copies of it in the same program. An well object should reasonably be usable in two isolated contexts without interference. That doesn't apply in every case, but it should be the default; don't limit the user of the code unnecessarily even if that user is you and you have everything planned out.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!