6 replies to this topic

[Xanather]

Im sure this keyword applies to many languages. It is the accessing of methods/fields/etc at the "class definition"? level.

I am about to rewrite most of my game after realising that the static keyword is, well, not logical in my case (I think atleast). I wrote many of my classes static - most of these classes were classes that I thought would only be initalized once. Although after realising how easy it would be to just recreate a corrupted object when a corruption occurs (by corruption I mean basically anything, from a multiplayer connection failing, to a incompatable object state) I was like "WHAT HAVE I DONE?".

What are other programmers thoughts on the static keyword in OOP?

Sure the static keyword can be extremely helpful in certain cases, but in general what do you think?

Thanks,
Xanather.

Edited by Xanather, 08 October 2012 - 05:41 AM.

[mrbastard]

In general static is useful when used as intended - as a property or method of a class of objects.

Note, you say "at the object level" which is wrong - normal non-static properties and methods are properties of objects; statics are properties of classes of objects. You clearly know this already, but it's worth getting in the habit of making the distinction correctly

It sounds as though you have fallen into the trap of prematurely constraining your design. While static (and Singletons in particular) are often misused in this way, the problem is with the process of design - YAGNI

[Telastyn]

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

In languages without a good module system (pretty much everything), they are a useful approach for global methods and constants (or near constants) if treated with caution.

[Xanather]

@mrbastard Yeah.. I knew that. I think I just typed it out wrong. edited. and yes I would admit to a bad design. Probably should have thought it through first.

Edited by Xanather, 08 October 2012 - 05:48 AM.

[Xanather]

In general static is useful when used as intended - as a property or method of a class of objects.

Note, you say "at the object level" which is wrong - normal non-static properties and methods are properties of objects; statics are properties of classes of objects. You clearly know this already, but it's worth getting in the habit of making the distinction correctly

It sounds as though you have fallen into the trap of prematurely constraining your design. While static (and Singletons in particular) are often misused in this way, the problem is with the process of design - YAGNI

Good read by the way thanks

[ankhd]

Hi all sure is lots of talk about the static thing. why, why.
I'm Holding all my Game Object Creation and types in a static class.
I did this because Im trying things out. My last game I passed all classes as params and that was a pain Im lazy foo.
So now Im using a ObjectManager Class. Goes something like this.


class cObjManager
{
public:

static vector<obj *>DefinedObj;

cObjManager(){}
~cObjManager(){}

static bool InitObjManager(things)
{
//load all type here and store them in a vector<obj *>
//must allways call this
return true;
}

static obj *CreateNewObj(Params)
{
search static list for the type we want and then create that type and return;
}


};//end class



now all I have to do is add the header to the file I want to use it in.
Call its Inmember once.
And coded like this Obj *newobj = cObjManager::CreateNewObj(Params);

It's so far is saving me time in writing code, looks like its working well so Ill keep going.

Hope that helps.. any way dont not use some part of the language, try it out and find the pittfulls.

[Olof Hedman]

Hi all sure is lots of talk about the static thing. why, why.
I'm Holding all my Game Object Creation and types in a static class.
I did this because Im trying things out. My last game I passed all classes as params and that was a pain Im lazy foo.
So now Im using a ObjectManager Class. Goes something like this.

Just a few notes on that class.
Since you never create any object, you don't need the constructor/destructor.
The whole class could also be just a couple of functions in a .h-file, and will work identically to that.
If you want the CObjCreator::somemethod-syntax, you could just wrap those functions in a namespace, and write a few lines less of code. (no static and public keywords)
That might also make it a bit more clear why doing it like this isn't really OOP-programming.