I just insist that singletons really are singletons; if you want a variation of a singleton locally in your program, that simply means you shouldn't be using a singleton in the first place.
The problem is that choosing a singleton early on, while seemingly convenient, makes changes later on much harder. I've a co-worker at the moment who is dealing with exactly this issue in a large Java application. Configuration singletons everywhere that's making refactoring and unit testing really, really hard.
As I understand it accessing any variable inside another package directly is EVIL :)
Ask yourself why people think it's bad? Then see whether it applies to the way singletons are often used :-)
When using a singleton, you ask the object to provide you with the data (thru a getter/setter or whatever mecanism you're using, anything BUT direct access), you don't simply take it. That's the difference between breaking or not breaking encapsulation.
How is it different when we're using a singleton to store static configuration information? Both are encapsulating the configuration information in one place (package variable vs object instance variable).
About the only place where a singleton class might buy you something is if you're configuration information is determined at runtime. That's the only extra bit of implementation you can hide more easily with a OO based solution.
The problem with sprinkling ConfigClass->instance->whatever everywhere in your code is exactly the same problem you get with sprinking $ConfigClass::whatever around everywhere. Really tight coupling that makes testing and refactoring a PITA.
In reply to Re^14: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
by adrianh
in thread what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |