16 replies to this topic

[sliders_alpha]

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.

[frob]

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.

[return0]

Static is evil for the same reasons you already acknowledge.

[Alpha_ProgDes]

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, 17 July 2012 - 05:38 PM.

[ApochPiQ]

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.

[alnite]

static is basically globals.

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

[krippy2k8]

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, 17 July 2012 - 07:05 PM.

[EJH]

"~=" 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, 17 July 2012 - 07:16 PM.

[TheTroll]

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.

[King Mir]

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.

[sliders_alpha]

why not have that as part of your current sector's information?

because their is 5626 sector in RAM at all time, this would only add 5.626MB but I'm trying to reduce memory usage, every pieces count.


from what I read using statics the way I do it is "ok" since they are all defined as final, and thus never changing
.

public class Global {
//Sector size
public static final int CHUNK_Z = 16;  
public static final int CHUNK_HEIGHT = 256;
public static final int CHUNK_X = 16;  
//nb de display list par chunk
public static final int DL_Y = 16;
//windows parameter
public static final int WINDOW_HEIGHT = 480;
public static final int WINDOW_WIDTH = 640;
public static final int WINDOW_BITPERPIX = 32;
//paths
public static final String ROOT_DIRECTORIE = "C:\\MEngCl\\";
public static final String TEXTURES_PATH = ROOT_DIRECTORIE+"Textures\\";
public static final String WORLD_PATH = ROOT_DIRECTORIE+"World\\";
//display area
public static final short DISPLAY_AREA = 30;
}

thanks for your awnsers ;)

Edited by sliders_alpha, 18 July 2012 - 12:25 AM.

[Telastyn]

http://gbracha.blogspot.com/2008/02/cutting-out-static.html

Some relevant info, though mostly I agree with Frob's first answer.

[demonkoryu]

I've accidently this blog post and I think its awesome because it explains [static] Singletons, why they're considered evil and how to use them properly.

Edited by demonkoryu, 23 July 2012 - 05:51 AM.

[Telastyn]

I've accidently this blog post and I think its awesome because it explains [static] Singletons, why they're considered evil and how to use them properly.

Shared state is shared state, even if it's private and scoped to a single class.

[Alpha_ProgDes]

why not have that as part of your current sector's information?

because their is 5626 sector in RAM at all time, this would only add 5.626MB but I'm trying to reduce memory usage, every pieces count.


from what I read using statics the way I do it is "ok" since they are all defined as final, and thus never changing
.

public class Global {
//Sector size
public static final int CHUNK_Z = 16;  
public static final int CHUNK_HEIGHT = 256;
public static final int CHUNK_X = 16;  
//nb de display list par chunk
public static final int DL_Y = 16;
//windows parameter
public static final int WINDOW_HEIGHT = 480;
public static final int WINDOW_WIDTH = 640;
public static final int WINDOW_BITPERPIX = 32;
//paths
public static final String ROOT_DIRECTORIE = "C:\\MEngCl\\";
public static final String TEXTURES_PATH = ROOT_DIRECTORIE+"Textures\\";
public static final String WORLD_PATH = ROOT_DIRECTORIE+"World\\";
//display area
public static final short DISPLAY_AREA = 30;
}

thanks for your awnsers ;)

I would agree that this use of static is ok, given the..... static nature of the data. I wouldn't complain about it. I couldn't see frob or telastyn really having a problem with it either.

[Telastyn]

Nope. Constants aren't mutable state so are fine to share.

[Oberon_Command]

I would agree with Telastyn that shared state in the form of mutable static variables is best avoided unless it really makes sense to do things this way. On the other hand, I would advocate the use of static functions (that is, static behaviour as opposed to static state) wherever appropriate, especially with helper functions. If a method doesn't actually need anything that you need to access through the "this" pointer of the class in which the method resides, then you should make it a static method (or free function, if you were using C++, which it seems you aren't) until it does. The "this" pointer is an implicit dependency - making your method an instance method basically states, "I need an instance of this class in order to function correctly." If that statement does not apply to your method, then it should be static. Don't add dependencies to your code unless it's really needed. Of course, if you really need to access instance variables later on, then you should use the method with that in mind. Throwing around a static method in code that's unlikely to ever see an instance of its owner class opens you up to the same kinds of problems that singletons have, most importantly that doing this will increase the amount of interdependencies in your program.

Edited by Oberon_Command, 23 July 2012 - 10:15 PM.