The problem is that choosing a singleton early on, while seemingly convenient, makes changes later on much harder.
If you model your app properly first, this shouldn't happen.
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).
But a variable encapsulate nothing at all! if I feed my configuration singleton from a flat file, and later I switch it to use XML, or a database, or whatever, I'll still use it the same way :
$singleton->param($somedata)
That's what's called encapsulation, right ? Accessing variables directly may work if you read only, but writing would be a complete mess...
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.
If your configuration data is strictly static, then you have no reason not to write it in the code directly in the first place, right ?
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.
It's a problem IF you can't easily switch configurations. Testing when you haven't tooled your code to be tested is hard anyway.
In reply to Re^15: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
by wazoox
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: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |