You may of course change a singleton, but changes to it are obviously global to your app. If that's not what you want, then you don't want a singleton.

But you might! The singleton class pattern isn't synonymous with static configuration. There are other uses for singletons.

Yeah sure, but in an OO-environment that means you're breaking encapsulation. Singletons don't.

Tell me how do singleton's break encapsulation any more/less than a set of package variables? If you're using them to return static configuration information (as you seem to be proposing) then they encapsulate exactly the same thing.

But you might! The singleton class pattern isn't synonymous with static configuration. There are other uses for singletons.

I don't really mean singletons are only for configuration ! 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.

Tell me how do singleton's break encapsulation any more/less than a set of package variables? If you're using them to return static configuration information (as you seem to be proposing) then they encapsulate exactly the same thing.

As I understand it accessing any variable inside another package directly is EVIL :) 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.

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.