....and apart from it being 'hidden' outside the class, it is still global data.
Actually, being hidden outside of the class is what makes it not global data.
static Vector in a GameObject Class
Actually, being hidden outside of the class is what makes it not global data.
Order of construction isn't what we're talking about, the fact is that the C::n var is still global data, and apart from it being 'hidden' outside the class, it is still global data.
What is global about it? It isn't visible globally (so modification outside of the class functions are impossible). It isn't in the global namespace (so name conflicts are not possible). You yourself said order of construction is irrelevant. Could you give us your definition of "global data" so we can be sure we're talking about the same thing here, and enumerate what problems, under that definition, make it an undesirable thing?
"global" is relative. What is meant here seems to be more like "nonlocal", or at least "less local than we might be able to get away with".
Static data almost always means something is bad. Rare exceptions exist. Types containing static collections of pointers to instances of self is a dirt common OO failure/antipattern.
Static data almost always means something is bad. Rare exceptions exist. Types containing static collections of pointers to instances of self is a dirt common OO failure/antipattern.
Say what???
There are a few hundred legitimate uses for static variables. There is nothing inherently wrong with a static, nor is their use, even in common use, a "code smell". You very often have a single resource with multiple instances around it. Like any other language structure, they can be abused and commonly are, but a static is no more an example of code smell than a pointer is!
I maintain that almost all application state could better be modelled nonstatically, as could most system resources usage. It may be that I have worked with pathological abusers of the "static state as application composition mechanism" pattern.
Global state (which is what we're talking about - not necessary global variables) makes sense when you're dealing with some sort of restriction imposed from outside your software entirely. For example, in the Windows API there are some functions that need to be called before certain functions are usable. The initialisation function only needs to be called once per *process*, so I emply a "construct on first use" system where the first class instance created will call the initialisation function, and set a static variable so future instances of the class don't duplicate the function call.
This does not violate encapsulation principles because the operation is hidden from outside the class, and has no bearing on the result of any publically accessable function calls on the instance. So you can construct any number of these objects and use them, and it doesn't matter which object did something special in response to global state as they all behave the same from the perspective of the calling code.
This does not violate encapsulation principles because the operation is hidden from outside the class, and has no bearing on the result of any publically accessable function calls on the instance. So you can construct any number of these objects and use them, and it doesn't matter which object did something special in response to global state as they all behave the same from the perspective of the calling code.
You example appears to be a workaround that uses hidden static state to "remove" references to other hidden static state. That seems to me like a great argument for eliminating hidden static state altogether!
This does not violate encapsulation principles because the operation is hidden from outside the class, and has no bearing on the result of any publically accessable function calls on the instance. So you can construct any number of these objects and use them, and it doesn't matter which object did something special in response to global state as they all behave the same from the perspective of the calling code.
[/quote]
I don't entirely buy this. What happens if I, or worse still another library that I might not be thinking about, likewise tries to call these special functions. Maybe I try to initialise these Windows subsystems differently Perhaps the two seemingly independent libraries now interact unusually together, preventing the program from starting up or causing confusing errors.
If I want to unit test this behaviour, how can I? I cannot mock out the library initialisation code and force it to return various errors, thus testing the different code paths.
I don't entirely buy this. What happens if I, or worse still another library that I might not be thinking about, likewise tries to call these special functions. Maybe I try to initialise these Windows subsystems differently Perhaps the two seemingly independent libraries now interact unusually together, preventing the program from starting up or causing confusing errors.[/quote]
You're more or less at the mercy of the operating system here. No coding convention can prevent other people's code from calling the same functions directly, but it's possible to prevent instances of the same class from doing so. The problem with trying to eliminate global state in this situation is that the operating system itself employs global state.
If I want to unit test this behaviour, how can I? I cannot mock out the library initialisation code and force it to return various errors, thus testing the different code paths.[/quote]
You can't, but containing the global state to the private portion of the object ensures the object can be used without spreading it's global state into whatever code creates an instance of it. Barring any bugs directly related to the initialisation process of course.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
