Re^14: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?

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.

Comment on Re^14: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ? Select or Download Code

Replies are listed 'Best First'.
Re^15: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ? by wazoox (Prior) on Mar 10, 2006 at 15:46 UTC
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)` [download] 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.	[reply] [d/l]

Replies are listed 'Best First'.

Re^15: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
by wazoox (Prior) on Mar 10, 2006 at 15:46 UTC

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)
[download]

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.

[reply]
[d/l]