I'm not aware of any "problems" from doing this. It's just like creating a global ClassObject of ClassName. Some people frown upon globals, but I have never really been much of a style whore. I'll leave it to somebody else to tell you whether its in good form or not.
its actually not bad,
but you are probably using it wrong.
classobject would usually be a alias for a pointer to that class/struct/union, thus in your program you wouldend have to write ClassName *Name, but only pClassName pName;
Some person, "I have a black belt in karate"
Dad, "Yea well I have a fan belt in street fighting"
GyroVorbis wrote:...or glorified globals like singletons and pretend that we aren't breaking the theory of OO design.
I'm curious as to why singletons are getting such a bad name these days. I've found them to be ideal for several projects. Having an object that can only instantiate itself ensures that you don't have multiple instancing floating around the server, chewing up more memory, and potentially stepping on one other.
At work, a buddy and I built a web-based chat / bidding application - kinda like a realtime eBay. They originally outsourced it to India and it ran like shit. It crashed the web server when more than 8 users got in a room - cuz it was chewing up so many resources. We rewrote the backend using singletons. Basically each room was only instantiated once on the server, regardless of the number of people in the room.
There was also a project where we needed a single instance of a runtime running on the webserver. Having more than one would screw things up because they would step on each other. Wrapping the runtime in a singleton did the trick.
I agree that singletons don't fit every case, but I'm surprised that so many people are against them.
GyroVorbis wrote:...or glorified globals like singletons and pretend that we aren't breaking the theory of OO design.
I'm curious as to why singletons are getting such a bad name these days. I've found them to be ideal for several projects. Having an object that can only instantiate itself ensures that you don't have multiple instancing floating around the server, chewing up more memory, and potentially stepping on one other.
At work, a buddy and I built a web-based chat / bidding application - kinda like a realtime eBay. They originally outsourced it to India and it ran like shit. It crashed the web server when more than 8 users got in a room - cuz it was chewing up so many resources. We rewrote the backend using singletons. Basically each room was only instantiated once on the server, regardless of the number of people in the room.
There was also a project where we needed a single instance of a runtime running on the webserver. Having more than one would screw things up because they would step on each other. Wrapping the runtime in a singleton did the trick.
I agree that singletons don't fit every case, but I'm surprised that so many people are against them.
the singleton design pattern is my fav
Some person, "I have a black belt in karate"
Dad, "Yea well I have a fan belt in street fighting"
Yeah, I agree. I honestly hate this whole OO whore movement that lots of indie developers seem to be a part of. It's like they are strictly adhering to this abstract idea of what is good and bad when coding based solely on what they read--it's clear that they don't have enough experience to decide what does and does not work for themselves.
These are also the same guys who make a million topics "IS THIS OO DESIGN OKAY?!?!" What good does it do if you question your overly complicated idea for implementation every step of the way? They are seriously working backwards.
I learned not too long ago how to be smart about game development. I am my own boss. I do as I please how I please. I make decisions based on what works for me and the project. I choose what will help further the project, not what the programming elitists say.
This is also why you won't really see me in C++ design topics commenting on OO implementations much. It's all too subjective for my liking. I'm all about the actual game development implementations of things. I will always be involved in those topics. But seriously, when it comes to bitchy OO design, count me out.
From a testing point of view (I'm taking a testing class), tracing dependencies is harder, which means that testing is harder, since most testing has to happen on the interfaces (read: interactions) between objects, since that's where things go wrong most of the time. You can't look at the class and say "this class uses this class", you have to go through the code itself, or attempt to automate such a procedure (and if it's harder for you to do it's harder to automate, right?)
Same problem with globals. And that's why globals/singletons are bad... apparently. Not that I care... yet :)
I realized the moment I fell into the fissure that the book would not be destroyed as I had planned.
MarauderIIC wrote:From a testing point of view (I'm taking a testing class), tracing dependencies is harder, which means that testing is harder, since most testing has to happen on the interfaces (read: interactions) between objects, since that's where things go wrong most of the time. You can't look at the class and say "this class uses this class", you have to go through the code itself, or attempt to automate such a procedure (and if it's harder for you to do it's harder to automate, right?)
Same problem with globals. And that's why globals/singletons are bad... apparently. Not that I care... yet
actually its alot easier to debug procedural code. there are no fancty things like JUnit or whatever they have these days.
testing suites are nice. but they do not do the job better in anyway. i believe that testing units and stadards were invented to make untechincal people understand how far along/ how fucked up a project on a technical level is.
showing a manager a pictures saying a the XML package has a bug with nice red colors, but thats the only thing that not working and we are fixing it.
is better than telling him, oh yeah, we have a major memory leak thats causing faulty data in the XML parser, but we dont know if its the parser because we havent tested to see if the function that support the XML class is giving it proper variables.
Some person, "I have a black belt in karate"
Dad, "Yea well I have a fan belt in street fighting"