What’s so bad about the Singleton?

Tweet

I keep running into people who caution against using Singleton and recommend to avoid it like a plague. What is so scary about it?
Kailash Badu

It’s a good question, for it is true that global variables are often demonised and more recently the Singleton has befallen the same fate. Perhaps a bit surprising, it is remarkably hard to find good arguments to support this common knowledge — Googling turns up a lot of confusion.

As I have often taken this stance myself, I found it reasonable that I should be able to argue for it, so I’ll try to give an explanation. This is also in part a follow-up on my post from last week, in which I present a way to avoid global symbols, without spending much time on why.

The anatomy of the Singleton

Some of the confusion around Singletons, comes from the fact that it is a manifestation of two different concepts, which each have a negative effect on an applications architecture. This muddies the case, since people tend to only deal with either one or the other of these two.

The most obvious of these concepts, is that the Singleton is a form of global state. It has this in common with global variables, as well as a couple of other — less obvious — manifestations hereof.

The other concept, that the Singleton contains, is that of static binding. Both of these are closely related to scope, which again has to do with drawing clear boundaries between sub-parts of a program.

But I’m getting ahead of myself.

Program state

Perhaps the simplest way to understand a program, is in terms of data and code. These two exists in separate worlds, with different rules associated. As the code executes, it manipulates the data, producing some kind of result. The data in a program, is known as state.

Since the basic unit of a program, is a function, state usually refers to the data, which relates to a function. A function is said to be stateful, if it changes it’s context, when run or if the context has any effect on the outcome of the function. Some times the term side-effects is used to describe the same thing. A function is said to be pure, if it always produces the same output, given the same input. For example, the following is a pure function:


function add($a, $b) {
  return $a + $b;
}

In the same terminology, a function which isn’t pure, is called a procedure. This is where the term procedural programming comes from. The following is an example of a procedure:


function add($a, $b) {
  echo ($a + $b);
}

Different shades of state

Global variables are a specific type of program state, but it’s not the only one. The above example (2) has a side-effect, without using a global variable — It writes out to the standard output. Another common kind of state, is mutable objects. For example, an object, which has a setName() -method, that changes the objects name, has side-effects (But the side-effects have a smaller scope, than global variables do). Even a local variable is stateful, within that functions body. While these are all examples of state, they represent different degrees on the scale.

What’s the problem, again?

As you may have guessed from the terminology (pure => good, side-effects => bad), it is implied, that state is bad.

The consequences of side-effects are two-fold. On one hand, they cause complexity. The problem is, that the i/o isn’t explicit. There is no way to know, by looking at the interface alone, what happens when invoking a function. This may be a small scale problem, but it adds up as the program grows.

The other problem is that of coupling. Since state can be shared between different functions, it may introduce a dependency between these functions. For example, if classes A and B both access the global variable G, then it is impossible to change G for A, without also changing it for B. This kind of dependency is called coupling.

There are remedies for excessive state in programs: Global variables can be replaced with local ones. Local variables can be replaced with function-calls (replace temp with query). Objects, which are passed around could be made immutable– This is especially important for long-lived objects, which interact with many parties.

Static binding

A program has two different kinds of existence; The compile-time and the run-time. Interpreted languages alternate between these, while a compiled language has a stricter separation. In any case, the symbols of a program, which take on a meaning in the compile-time, can’t change it’s meaning in the run-time. Examples of such symbols are constants, literals, class names and static methods (And in PHP, floating functions). Runtime-symbols (variables), on the other hand, can change their meaning.

Even though static symbols can’t change, they can still influence the outcome of a function, so in a very general sense, they are a form of state. It is usually not as important to avoid the state of static symbols, but in some cases, they may cause the same problems, as run-time state does. For example, static method calls cause static (compile-time) coupling. The Singleton is a prime example of this kind of coupling; If class A uses singleton S, then there is a strong coupling between A and S.

coupling

Coupling is of course unavoidable and to some extend even desirable. However, just like with run-time state, limiting it is a good idea. The problem with static coupling, is that it makes it hard (or even impossible) to reuse a component in isolation from other components, which it is coupled to. This is usually not an immediate problem, but it can have impact on maintenance. It also makes it hard to unit-test and debug code, because it isn’t possible to isolate a part of your program.

That’s all

I only just scratched the surface of the topic, but I hope this offers some explanation of why globals are frowned such upon. I’ll just leave you with the following quote:

Forgive Me Father, for I Have Singleton’ed
Kevlin Henney

Comments are — as always — welcome, but please refrain from biting off heads (Mine or others).

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • heggaton

    I can’t say I agree with not using a singleton. I’m sure there are pros and cons for differing circumstances but I can tell you this: When implementing a resource intensive function that only needs one instance, you can’t go past a singleton.

    I’d like to know how you go about avoiding them. I’ll provide a circumstance: Acquiring a database connection is often resource intensive. You (in this circumstance) only need one connection for several tasks, how would you implement it without using a singleton?

  • Alexander Schearer

    You haven’t really shed any more light on the matter. I understand that complexity is a problem as an application grows in size, and that coupling is a common manifestation of complexity, but it’s not clear to me why a singleton, or other global data, should be uniformly avoided.

    You equivocate at the last minute when you admit that coupling is sometimes desirable and almost always unavoidable. That being the case the decision to employ the singleton pattern (or other global state) is transformed into a trade-off, and like many trade-offs there are all sorts of cases to be made for going either way.

    One such case was argued in the last post on this topic — namely simplicity. That is to say that there are two threads of complexity at play in this problem; I think we can call the first architectural complexity and the second human complexity. It’s possible to be too clever when creating an application, which is often the case when avoiding singletons, and this will have a its own negative impact on the development process.

    In the end are we just left saying the usual, “Do the appropriate thing for the task at hand”?

  • Ivo Jansch

    One important thing to realize is that a singleton in php is conceptually different from a singleton in other environments. A true singleton guarantees that at any one time, only one instance of an object is present. For PHP, this is the same, but the subtle difference is that a singleton in PHP is singleton *per request*. This means that across requests, with simultaneous users etc, you will have multiple instances.

    Don’t confuse what you call ‘pure’ with ‘deterministic’. Deterministic functions are functions that, given the same set of input, always have the same return value (state does not influence the outcome). In your case, in what you call a ‘procedure’ (a concept not commonly applied to php) you echo something, but you don’t change the application state in any way. Any code before or after will still behave the same, so I wouldn’t call that ‘unpure’. It’s just an output function.

    Finally, be aware that singletons make unittesting slightly more difficult. If there’s only one object with only one state, it’s hard to test muliple variations of the singleton.

  • http://chris.unigliding.co.uk Stormrider

    I agree with using something like a singleton for database connections etc. What would be your solution instead? I’ve used something like this before, is this better or worse than using a singleton?

    function getDBConn() {
    static $dbConn;

    if (empty($dbConn)) {
    $dbConn = new mysqli(HOST, USER, PASS);
    $dbConn->select_db(DATABASE);
    }

    return $dbConn;
    }

  • kyberfabrikken

    I’ll take the easy one first. A database connection could be passed in to the objects which need it. You can go all the way and pass it to each function that needs it, but a reasonable tradeoff would be to pass it in the constructor.
    A database connection is a poor candidate for a global variable (or Singleton). You usually have just one database connection open, but you might run into situations, where you need multiple. For example, if you wanted to synchronise two versions of the same application with each other. Or if you want to write unit-tests.

  • Pingback: PHP Coding School » Blog Archive » php code [2008-02-13 09:48:16]

  • Ferry Boender

    > In your case, in what you call a ‘procedure’ (a concept not commonly applied
    > to php) you echo something, but you don’t change the application state in any
    > way. Any code before or after will still behave the same

    Not true. Output does change the state. The warning: “Warning: Cannot send
    session cookie – headers already sent by (output started at..” clearly shows it
    does.

  • Ferry Boender

    One of the main uses for singletons appear to be database connections. The reason I personally believe using singletons for database connections is bad is because a database connection itself has state too. When you try to retrieve a new database connection, and the singleton returns a database connection which is already open, you automatically inherit the state of that connection. That is something you might not want. Who knows what kind of state the connection is in? There might be temporary tables, uncommitted transactions, etc.

    Most of the hard programming problems are related to unexpected states. For database connections, this is a problem which is almost unavoidable, and singletons are not the way to avoid those problems, they only make it worse.

  • kyberfabrikken

    @Alexander
    You’re perfectly right — It is a trade-off, and as such it can be justified. It’s very easy to get hung up in absolute terms, when speaking about software design decisions — In fact, they are almost always relative to their context. Thanks for pointing that out.

    The problem of the Singleton is relative to the applications size. From that follows, that in an application of a certain size, the cost of using a Singleton is simply too great. It is my belief, that the break-even point lies quite early on.

  • http://chris.unigliding.co.uk Stormrider

    Surely passing the database connection around in constructors and things defeats the whole point of maintainable code – you have just littered your code with passing databases objects around, and sometimes finding contrived ways to do so that avoid using global variables or functions. It just makes more sense to me not to have to pass it around all the time when there is no need to do so.

    Personally, I think far too much fuss is made about polluting the global namespace and using functions outside classes etc. If you are planning to integrate your work with other people’s projects, then it is a valid concern, but if you are writing a standalone application, I really don’t see why there is such a fuss. I wouldn’t use global variables because they are a nightmare to track and work out what is going on, but I have no problem with ‘global’ functions. I don’t use singletons because I think there are better ways of doing things, but still.

    And yes, the database does have a state, but I don’t see that as being something that stops you using one object. The trade off is that vs having to connect to the database multiple times (or at least have the connect function run and work out there is already an open connection). In the function I showed above though, since it is not passing by reference, the original database connection is ‘clean’ – a freshly opened connection. Other classes then take a copy of it by calling $dbConn = getDBConn(); or similar, use their copy, then throw it away. Each time you call getDBConn() you get a copy of the ‘fresh’ connection, while still not having to call the connect routine multiple times.

  • kyberfabrikken

    In your case, in what you call a ‘procedure’ (a concept not commonly applied to php) you echo something, but you don’t change the application state in any way. Any code before or after will still behave the same, so I wouldn’t call that ‘unpure’. It’s just an output function.

    That’s bordering on being philosophical. I deliberately picked that example, to make the point that changes to I/O constitutes state. For example, if you were writing software to control nuclear missiles, it would matter a great deal, whether you sent the command to launch or not.

  • kyberfabrikken

    Personally, I think far too much fuss is made about polluting the global namespace and using functions outside classes etc.

    I didn’t touch on the topic of “polluting the global namespace”, since I think that is of less importance; Coupling and side-effects are the real dangers of global symbols.
    Likewise, I’m quite fine with floating functions, as long as they are side-effect-free.

    In the function I showed above though, since it is not passing by reference, the original database connection is ‘clean’ – a freshly opened connection.

    I’m not sure I follow you? Objects are always passed by reference in PHP. You have to explicitly clone, to do otherwise.

  • http://chris.unigliding.co.uk Stormrider

    OK, I’m just getting a bit confused with terminology and what is passed by reference and what isn’t :P

    Regardless, the state of the object shouldn’t make a difference to the way the application works. It is easy enough to ‘reset’ the object after a query or something if you wanted to.

    Besides, if objects are always passed by reference anyway, how does passing a variable around in constructors help with coupling? Surely the problem still exists.

  • Ferry Boender

    > Regardless, the state of the object shouldn’t make a difference to the way
    > the application works. It is easy enough to ‘reset’ the object after a query
    > or something if you wanted to.

    Because if the object is a database, you can’t reset the state easily. Suppose
    some other code started a transaction on the database? There’s no way to ask a
    database link if a transaction is currently running. Besides, you don’t know
    wether the transaction should be rolled back or commited. The state is unknown,
    undiscoverable and unchangable. Taking a copy of the link from a singleton will
    not reset that state.

    > Besides, if objects are always passed by reference anyway, how does passing a
    > variable around in constructors help with coupling? Surely the problem still
    > exists.

    The problem I describe above still exists, yes, but it is easier to debug
    because you can tell where the database connection has been by looking at
    backtraces. Also, it becomes the caller’s responsibility to provide a ‘clean’
    database connection, not the code itself. Suppose one day it is decided to
    rewrite the application with threading? The state of the database connection
    would then become completely unreliable. So you’ll probably want to have one db
    connection per thread. You’d have to modify all the code instead of just the
    calling code which passes the database connection. You could modify the
    singleton to keep track of the various threads and return new connections to
    each separate thread, but then your thread handling code is scattered all
    over the place and now a basically random piece of code somewhere is responsible
    for making sure other code gets the right thing. Just passing a connection when
    calling the code would’ve been cleaner, in my opinion.

    I don’t think the problem is so much about coupling, it’s more about clarity
    and a single point of entry. That said, I’m sure there are good uses for
    singletons (I just haven’t seen them yet), but a lot of the stuff they’re
    used for right now don’t seem to be it. There seems to be a little too much
    of the “Oh, it’s a pattern, it must be a good idea!” thinking going around.

  • http://www.jhauser.com datune

    In most real world situations you can’t go by without using a singleton for database connections, passing a db connection around to objects is nnot really a good soluition (for tiny aopplications it may be), but if you work in a corporate environment where you have to be able to connect to MySQL, MSSQL and Oracle, you can’t go ahead and pass in multiple DB connections, and believe me, it happens quite often that 2 different connections are needed in a single method.

    I think some people have way to much time, and honestly this post seems to be about generating buzz and fuzz more then anything else, no offence ment ;-)

  • http://chris.unigliding.co.uk Stormrider

    > You’d have to modify all the code instead of just the calling code which passes the database connection.

    You’d have to modify the code each time it is passed in a constructor though, surely? I think having the singleton / static function handling which thread gets what connection is a perfect solution – that doesn’t scatter the code around at all, but it is all in one place – that function!

    Passing a connection around requires the code around that to get the connection, create a new one if needed and all the logic behind that, then passing it. I want the API of my application not to have to deal with things like that, but have it all done behind the scenes, where it belongs.

    The point you raise about database transactions is a good one, but the project I am using this on at the moment doesn’t have any complex queries etc, and isn’t that big an application. Also, passing the DB connection in the constructor doesn’t actually solve this at all, the problem is still there!

    If I wanted to protect against that, I could use proper transactions, or locking tables or something, but you would have to do that anyway, surely?

    I could very easily modify the code to decide if a query is being used, and not hand out the link until the database is free, with each piece of code that uses it telling the function when it has finished with the resource. If I passed the DB link in constructors for every object, I would have to code for this every time, but I can easily put it in a function this way, where it is much more maintainable and easy to modify.

    I think the actual singleton syntax is very bloated given that you can make it much simpler in more recent PHP versions though. I also don’t think a singleton should be an object – it is kind of abusing OOP principles. But using a static variable in a function seems like an ideal solution to me.

  • Russ

    Time to remove sitepoint from my RSS feed. The site is clearly going quality over quantity. This article is another good example. What could have been a well written, well thought out stance on the positives and negatives of singletons; was instead a poorly written blog post at best. With a million blogs on the web, the editors at sitepoint really need to step up and edit if you wish to keep your audience.

    After reading sitepoint since early this decade, it’s disappointing to lose what was once a great resource for technique and design.

  • Pingback: SitePoint PHP Blog: What’s so bad about the Singleton? | Development Blog With Code Updates : Developercast.com

  • http://www.foundline.com/ bradley.holt

    One of the questions that this article brings up is, “What are the alternatives to using a singleton?”

    There are two immediate alternatives that come to mind. One option is to use the registry pattern where you have one registry class (that is probably a singleton itself) with which you can register your object instances. The downsides are that you still probably have one singleton (the registry itself) and you now have a dependency on the registry. But, at least all of your classes don’t have to be singletons and you can swap out implementations in the registry.

    The other alternative is to use a dependency injection container. This is similar to a registry but your dependent classes don’t need to have a dependency on the registry/container in order to get their dependencies satisfied as their dependencies will be “injected” by the container.

    The end result of both approaches is that, effectively, you still have singletons but the singletons are managed by something else, not the class itself. This allows you to easily swap out different implementations at run time which is especially useful when testing with mock objects.

  • Pingback: SitePoint PHP Blog: What’s so bad about the Singleton? | Development Blog With Code Updates : Developercast.com

  • chiborg

    I am a bit sceptical about “replace temp with query” – AFAIK there is a (very small) performance penalty when calling functions in PHP. Maybe this refactoring pattern is only for Java and not for PHP?

  • apinstein

    The poster is confounding two problems.

    It is true that a deterministic function (same output given input) is easier to test and maintain than one that is non-deterministic.

    However, the presence of singleton’s in a program do not cause non-deterministic functions. It’s the presence of singleton access in a function that causes the problem.

    The poster doesn’t seem to understand that using data from a singleton in a function isn’t the SINGLETON’S fault. It’s the programmer’s fault. If that function needs access to a piece of global state, why not pass it in as an argument, thus resolve the issue with creating a non-deterministic function while at the same time allowing use of a singleton.

    This is also a good reason to use tests. If you write a function that needs information from a singleton, then your test setup should deal with the possibility of various values of the global state. Then you can change behaviors as needed an catch bugs.

    As the poster suggests, it is a best practice to reduce all unnecessary coupling for the sake of simplicity and maintainability.

    To me, this post is the equivalent of saying “Hammers suck because I used one once to open a box of glasses and all the glasses broke.”

  • Pingback: roScripts - Webmaster resources and websites

  • http://www.magain.com/ mattymcg

    The site is clearly going quality over quantity.

    Russ you’re welcome to go spend your time trawling through the upcoming stories of digg if all you’re interested in is quantity.

    Nice post Troels.

  • http://chris.unigliding.co.uk Stormrider

    “To me, this post is the equivalent of saying “Hammers suck because I used one once to open a box of glasses and all the glasses broke.””

    I love this quote!

  • HarryF

    Think Ivo’s right that PHP singletons are not really the same as Java singletons, as they won’t outlive a request. Perhaps these are the real singletons in PHP: http://www.php.net/manual/en/language.types.resource.php

  • Ivo Jansch

    “if you were writing software to control nuclear missiles, it would matter a great deal, whether you sent the command to launch or not.”

    You missed my point there. The fact that it launches a missile does not change its state. If every call to the function launches a missile, it’s still pure, and no state is affected. On the micro level, this call echo’s something, and does so on each call, no matter what the state of the application is. (note that in your example the missile state is not part of your application). If you were to wrap this in a unittest that uses output buffering to catch the command, you can call it a zillion times and it would still echo the same thing. So in my opinion it’s fairly pure. However, it doesn’t really matter for the point your making so I’ll stop arguing about it. :)

    Different subject: The example of database connections mentioned by some commenters is a very good one; many open source php packaged have trouble connecting to an external database, because they made the wrong assumption to make a connection a singleton. You can have as many connections as you want, it’s not a singleton. Sure, you want to minimize the number of connections necessary but a singleton is not the best solution to do that (creating a pool, or putting them in a registry may work better).

  • http://www.foundline.com/ bradley.holt

    Think Ivo’s right that PHP singletons are not really the same as Java singletons, as they won’t outlive a request.

    The fact that the PHP lives and dies by the request/response cycle does not mean that PHP singletons are not really singletons. Singletons in both PHP and Java are singletons within their given execution scope. With Java the execution scope is the running JVM. With PHP the execution scope is the request/response cycle.

    I would argue that Java singletons in a web application can lead to worse design problems than PHP singletons. With PHP it is very clear that your singleton will only be a singleton within particular request/response cycle and you design them with this in mind. With singletons in a Java web application the scope of the singleton is the JVM that it is running within. If you design your application assuming their will only every be one JVM then your application will break as soon as you introduce load balancing and have it running on two or more JVMs. At least in PHP the singleton’s scope is very clear.

    This is not to say that you can’t have a share-nothing architecture that can scale out in Java web applications. I’m simply saying that in a Java web application you need to wary of creating shared resources (like singletons) since they could break as soon as you scale out to more than on JVM.

  • rainwebs

    Interesting to read that there’s still a discussion. My comment in context to a Spring Container from 2006 to this ;-):

    How to Decontaminate a Singleton

  • blueyon

    I can’t belive so many people here don’t know what the alternative is to using a singleton!

    You store the instance of the class in a registry and then pass the registry around to classes that need it.

    Look on http://www.phpit.net to see how they do it or even Code Igniter.

    This is the correct way to pass instances around.

    Theres just to many bad examples on the net of how to pass dependances around.

  • Pingback: Web 2.0 Announcer

  • Laars

    For the love of all that is good, Troels, please learn how to use correct punctuation. In particular, your excessive overuse of unnecessary commas can only hurt your credibility.

  • kyberfabrikken

    For the love of all that is good, Troels, please learn how to use correct punctuation. In particular, your excessive overuse of unnecessary commas can only hurt your credibility.

    I know. In Danish (My native language), there are three official set of comma-rules. As a result, nobody knows how to do it properly. Me inclusive.
    I know, that’s a really poor defence, so I’ll try to make an effort in the future.

  • phpimpact

    @Laars: Do a search and replace on the commas and stop complaining :D

  • fresh

    The consequences of side-effects are two-fold. On one hand, they cause complexity. The problem is, that the i/o isn’t explicit. There is no way to know, by looking at the interface alone, what happens when invoking a function. This may be a small scale problem, but it adds up as the program grows.

    Ok, but if we pass around everything in a registry instead, then how can we know what a component does with the passed-around object? I see the same problems as before: The registry grows so big and is used in so many places, that again everything depends from everything.

    Now it’s no longer a ‘hidden dependency': A constructor asking for a $registry parameter tells us “the new object might depend on or manipulate anything you stuff into the registry, in any of its class methods.”

    What does this information help us, compared to “the new object might depend on or manipulate anything you define in the global namespace, in any of its class methods.”

    That said, I agree with the arguments about flexibility/reuse and unit tests. The question will be, how much flexibility is actually needed.

  • fresh

    How much flexibility do we want?

    One argument against the singleton and global symbols is that we cannot reuse the code in an environment where these global symbols don’t exist, or have another meaning. And, that we cannot easily tweak the global symbols, to see how our component performs in a different situation – as opposed to passed-around parameters, that we can easily tweak for every component individually.

    Now, that applies to some other global symbols as well: Someone might get the idea that the ‘+’ symbol is too unflexible. Instead, we should define an arithmetics interface, and then put an implementation of this interface into our registry object, passed around to components which use it. So, we would write
    $result = $registry->get('arithmetics')->add(5,6);
    and have everything configurable.

    Wow, this could even make sense in some rare cases (floating point vs rational numbers..)!

    But, usually we will have a bunch of global symbols that we want to use explicitly in-place, and not have configurable. This would be the core language (obviously) and some library functions or classes. The consequence is that we cannot use our code in another language, or without the library. And, we cannot test our code with a different implementation of the ‘+’ operator. The deal is, we live with this constraint, as everything else would be a pain.

    The consequence of singletons and static binding is that our code does not work without the global symbol. That’s a constraint, yes, but maybe is it really so much worse than the above constraint? Our component might be so entangled with the entire application, that we don’t even think about reusing it somewhere else.

    In this case, couldn’t it be a good idea to live with explicit class names (and evtl a singleton) inside the components? We lose some flexibility, but we gain transparency: With only one glimpse at the code, you know the type of an object. And, you can be sure that nothing gets lost on the way of passing around parameters.

  • fresh

    And one more.

    My components are OOP, but my starting point index.php is not. Or, not really. It’s rather a sequence of commands, meant to read all the settings, initialize the __autoload and include some files manually, and finally launch the MVC mechanisms.

    I would say that in this phase of the program, we don’t care about reuse and flexibility. What we can already care about is encapsulation and separation of things, and hiding stuff away. Here I imagine some static class methods could be quite useful, to bring some order into the mess. It will still be possible to avoid using the singletons in the OOP application components.

    Or not?

  • Phil

    I think the point about unit testing is a bit of a fallacy.

    If your unit testing framework cannot handle mocking singletons it’s a deficiency in the unit testing framework.

  • kyberfabrikken

    @fresh
    Those are all very good points. I’ll try to address them in sequence.

    Ok, but if we pass around everything in a registry instead, then how can we know what a component does with the passed-around object? I see the same problems as before: The registry grows so big and is used in so many places, that again everything depends from everything.

    That is true. There are two things that makes the registry an improvement over a singleton. The first is that it offers a flex-point; This is especially useful in testing, since it allows you to substitute a single component with a mock. The other benefit is that a single monolithic registry is the first step towards a finer grained collection of registries. You can fairly easy refactor towards having a number of registries. Eventually these registries might be possible to turn into actual objects.

    But eventually, a registry has one of the same root-problems as singletons; global state. A solution to this could be finer grained registries (As already mentioned) or dependency injection.

    The consequence of singletons and static binding is that our code does not work without the global symbol. That’s a constraint, yes, but maybe is it really so much worse than the above constraint? Our component might be so entangled with the entire application, that we don’t even think about reusing it somewhere else.

    Put on the extreme end, you are right; What could be said about one static symbol, can be said about every static symbol. There are certainly uses for redefining a seemingly basic operator such as +; Time, money, floating points and other complex types comes to mind. Generally though, I would agree that language features should be kept alone, unless there is some considerable gain to yield from replacing it. However, there is a big difference between not redefining defaults and actively introducing them. What I’m advocating, is that userland code should refrain from introducing new static symbols. I would not suggest to try and “correct” the limitations of the language, using userland workarounds.

    Here I imagine some static class methods could be quite useful, to bring some order into the mess. It will still be possible to avoid using the singletons in the OOP application components.

    Or not?

    I would say that you could equally well write the bootstrapping without singletons, as you can with. They don’t pose much of a problem on this level, mostly because it is already “spoiled”. Eg. you can’t unit-test it anyway, because of all the side-effects, so adding a singleton kind of drowns in the noise.

  • kyberfabrikken

    To me, this post is the equivalent of saying “Hammers suck because I used one once to open a box of glasses and all the glasses broke.”

    And to me, this quote is the equivalent of saying “Guns don’t kill people. People with guns kill people.”

    In a narrow sense, you are right but the way most people use singletons, isn’t as it’s described in GoF. In this case, it’s a matter of signalling intend. If you implement a class as a singleton, an outside programmer will naturally suspect that it’s used for gaining global access deep from within your program. The uncertainty can be damaging on its own.

  • fresh

    Some comments.

    (I apologize for that much long-winded detail and eventually going off-topic, but without that it will be hard to see how the concepts apply to reality.)

    The other benefit is that a single monolithic registry is the first step towards a finer grained collection of registries. You can fairly easy refactor towards having a number of registries. Eventually these registries might be possible to turn into actual objects.

    Are we talking about different registries that have to be passed one-by-one? Like

    $controller = new MyComponentController($registry1, $registry2, $registry3);

    or

    $controller = new MyComponentController();
    $controller->setReg1($registry1);
    $controller->setReg2($registry2);
    $controller->setReg3($registry3);

    or

    $registry->set('section1', $registry1);
    $registry->set('section2', $registry2);
    $registry->set('section3', $registry3);
    $controller = new MyComponentController($registry);

    As I understand, these are all different ways of dependency injection. What they have in common is that we either have to know which information the component will need, or that we have to generously inject everything.

    Now, let’s have a look at an example.
    Some things that our view classes (or even the templates) will need:
    – information about the user and the session: Does he have admin rights? In which language is he surfing? Depending on these things, some layout elements might not be displayed, or displayed in a different way.
    – shared layout elements (let’s call them widgets) like menu, calendar, advanced time display (‘this was posted * minutes ago’), avatar pictures etc.
    – Some of these shared layout elements might again need information about the user, the environment etc, or might even need an own database connection (the calendar for instance, to look into the calendar database).
    – In the current design there is a ‘page’ object where different layout components are buffered, to be finally assembled in a centralized place (page.php). I don’t like the specific way we do it, but I’m also not going to change it that soon.

    Typically, our controller will not know which of these things are needed in the view classes (except for the page object, which is needed in any case) – a designer might choose, out of the blue, to use a calendar or other layout elements, or to add some power controls that require admin rights.

    With dependency injection or registry we would have to pass around a ‘widget factory’, a ‘user’ object etc, all injected one-by-one with setters or constructor parameters, or stuffed into a passed-around registry. And the widget factory for itself would also need to know how to get information about the user and the database, and pass that information to those widgets which need it. (another question is, how MVC can be applied to autonomous layout widgets)

    Currently we do much of the above with singletons and static functions. Maybe at the cost of flexibility, but so far we have not really missed it – most of all because we did not try anything that requires flexibility. What we win is transparency – which means, you always know where a function is implemented.

    However, there is a big difference between not redefining defaults and actively introducing them. What I’m advocating, is that userland code should refrain from introducing new static symbols.

    Ok with that. Maybe the ‘+’ example was a bit exaggerated anyway.

    Some static symbols in PHP are the $_SESSION, $_GET and other global variables. Maybe the ideal way would be to hide these things in objects. But, it does already help to hide these things behind static class methods – if only for making it easier to prevent arbitrary write access.

    Another typical example for static symbols is a class constructor, or a static factory method. If we don’t want static symbols to be used globally, we have to take care that a explicit constructors (as any static symbols, including singletons and static factory methods) are only used in the “bootstrapper” (where the hell does this word come from) and inside the component they belong to.

    I would say that you could equally well write the bootstrapping without singletons, as you can with.

    The benefit I see in static class methods (eventually with private static variables that behave like singletons) in bootstrapping is encapsulation. We can have private methods that load a bunch of ini files, etc. Better than having all that in spaghetti. And, we don’t have to say “load setting X” and later “use setting X” – we can just say MySetup::getX(), and the setup class will load the things if-not-done-yet.

  • fresh

    @myself:

    The benefit I see in static class methods (eventually with private static variables that behave like singletons) in bootstrapping is encapsulation. We can have private methods that load a bunch of ini files, etc. Better than having all that in spaghetti. And, we don’t have to say “load setting X” and later “use setting X” – we can just say MySetup::getX(), and the setup class will load the things if-not-done-yet.

    Even better: Assume that we usually write some defaults into the $_SESSION when it’s empty, and eventually allow the user to switch these values. With a singleton or static methods, we can encapsulate all that: “MySettingX::get()” will look if the session value is already set, and if not fill it with defaults.

  • McGruff

    Singletons are unequivocally a bad choice for the reasons mentioned above (although a singleton registry can have its uses). You won’t ever see them in a good OOP design.

    The problem with encapsulating code in classes is that everything is locked up in separate components: how to get all the bits talking to each other? Who gets a reference to what is the basic problem of OOP design. Simply making things global to get around that is a bit of a cop out. Instead you should figure out how to pass objects around where they are needed.

    Factories, a registry, or a dependency injection container can manage lifecycle if you genuinely want a single instance. Object assembly is really a layer all of its own. Good things happen when you pull that out from the rest of the code ;)

  • Pingback: SitePoint Blogs » Interpreting the Results of the SitePoint Reader Survey, Part 2: Content

  • fresh

    Hm, what about inheritance?
    One more place where we use explicit classnames!

    In our project we are already at a point where I would like to have “dynamic inheritance”.

    Our pages are implemented as classes deriving from a MyProjectDefaultPage class for the unified layout. Quite a nice thing, because this allows a huge number of extension points. For instance, for the top menu, we can simply reimplement the “getTopmenuActiveItem” and return the name of the active menu item. And “getSubmenuItems” to return a formal list of items to show up in the submenu. Then we can make one more layer of subclasses that all share this submenu, but have different implementations of “getSubmenuActiveItem”.

    (I hope this was understandable)

    Now we might get at a point where we want to introduce skins. For this we would want to replace or extend the MyProjectDefaultPage with something else.

    Ideally something like this:

    $active_skin = ‘AlternativeSkin';

    AlternativeSkin::SomeSpecificPage extends DefaultSkin::SomeSpecificPage

    SomeSpecificPage extends $active_skin::DefaultPage

    $active_skin::DefaultPage extends DefaultSkin::DefaultPage

    This time it’s not about singletons, but still about static symbols that we want to be dynamic.

  • Sly Gryphon

    I don’t see what the comments on static binding have to do specifically with singletons, as opposed to other ways of giving class A a reference to an instance of class S.

    “If class A has a dependency on class S injected, then there is a strong coupling between A and S.”

    “If class A has class S passed into a method, then there is a strong coupling between A and S.”

    In all cases, if class A calls method S.Foo(), then there is a compile time dependency from A to S. Note that in all three cases the actual instance of S used can vary (including a subclass).

    The primary difference between passing as an argument, dependency injection and singleton is how easy it is to change *when* the instance of S used is changed.

    – For a method argument it is easy to use a different S each time. (You can use the same S each time if you want).

    – For dependency injection it is easiest to set the instance of S once when A is created; if you want to use the same S this is easier than passing an extra parameter each time. (Note that you *could* change the instance of S held by A before each call, but it’s not as easy as if passed via a method.)

    – For singleton it is easiest to set the instance of S once for the whole program. (Note you can still change that instance before each call).

    Another consideration when ‘changing’ the instance of S is threading. If there are multiple threads potentially accessing the singleton (or class A’s injected S), then you would need to lock to isolate the different S’s. (Passing in as a method argument does not need the lock).

    Note the same things can be done with all designs, just the ease of doing them differs. If you need a different instance of S each time, have multithreading issues, and have S readily available, it does not make sense to use a singleton and have to lock it each time (in fact, it’s stupid).

    On the other hand, if you only have one S, the same S used by all, and it has no state that is going to screw up threads, then a singleton is easier than an additional argument passed through all layers of your methods.

    One other aspect of the static binding that does differ between the methods is how obvious the static binding is: a method clearing has a paramter S; dependency injection has parameter S on the constructor (or a property of type S); use of a a singleton, however, is not visible in the public interface. (Many other solutions, such as extracting from a generic registry, also don’t explicitly have S in the public interface).

    Remember, in all these cases, that the Singleton pattern does not prevent you having multiple instances (e.g. one per thread) or varying instances (the singleton can be any subclass of S). These are actually two of the benefits of the pattern from the original Design Patterns book (consequences 3. Permits refinement and 4. Permits variable number of instances).

    In fact, the ability to use a subclass is one of the primary reasons in Design Patterns for using the Singleton pattern: “Use the Singleton pattern when … instance should be extensible by subclassing and should be able to use an extended instance without modifying their code.”

    From the point of view of unit testing, this is brilliant: the target code uses the singleton to provide services/functions, and all your test code needs to do is configure the singleton instance with a stub implementation (e.g. mock).

    A final note: using a registry to hold a collection of instances is one of the implementation issues actually discussed in Design Patterns as a “flexible approach”. In Patterns of Enterprise Application Architecture, Fowler further expands on the Registry pattern, as a particular implementation of Singleton.

    Sly Gryphon

  • http://ioreader.com bestweb

    Alright, this might have already been hashed out but I cannot bother myself with reading all the comments. There are several problems with singletons ranging from predictability to garbage collection.

    Predictability/Hard Coupling:
    These two issues are closely related. It is difficult to measure just how dependent (in this case, highly) on piece of code is to another when inputs aren’t explicitly being passed around. A function is deterministic insofar as given the same set of inputs it will return a single output. Unknowingly outputting or modifying the state of a foreign object is a side-effect. Given a singleton, it is impossible to say a function/method is deterministic. This is the case for two reasons: i) given that the singleton is not explicitly passed to the function, for any number of function calls there is no measure to show that the singleton’s state hasn’t changed, and given code dependent on the state of the singleton, the function’s return will be different, ie: not deterministic; ii) the function might modify the state of the singleton, the altering the rest of the program in an unpredictable way.

    Garbage Collection
    Although PHP runs as distinct processes, this is still applicable and definitely generalizable to other languages. When does a singleton object get garbage collected? In the case of PHP, it is likely collected when the current process is terminated because it never loses scope–regardless of if it used in the program or not. In essence, this is a memory leak.

    Inheritance
    If the singleton is implemented by using a class (eg: a registry), then extending the singleton class is a pain. Given a purposeful singleton class, extending it and using both the parent and child subclasses causes unwanted overlap with the static members. Obviously, this is an avoidable problem that leads to another unfortunate problem: boilerplate code because each singleton class needs to be separate.

    This should be an indication to anyone using singletons that they are doing something wrong. In general, using singletons with classes is a hack to make object-oriented code more procedural. Boilerplate code is a signal to refactor code.

    Final Thoughts
    The general pattern I see is that for new programmers, the singleton appears to be a panacea. Unfortunately, the benefits of singletons are more apparent than real. At first, their conveniences seem amazing. However, as code bases grow, singletons have the effect of making code less maintainable. Their intended use–to have one and only one instance of a particular class–can be factored out into other solutions. Some commenters seem averse to passing references to classes as function arguments. This could be for a few reasons: a) they don’t understand call by reference, b) their functions already have a prohibitive number of arguments, c) they’re code base is highly dependent on their usage of singletons. Besides the last one, these problems are trivial. So why ought one pass objects by reference as inputs to places where they are used? One of the strongest points is that the code becomes implementation independent. The second you use a singleton, you are locked into the same instance of the same class. As kyberfabrikken exampled with database connections, by passing dependencies as arguments to functions, you are not limited to only one resource, and the same is generalized to one implementation. If this doesn’t seem important then please take a minute to think about it as the implication is important with respect to modularity and maintainability.

  • Benjiro

    Some commenters seem averse to passing references to classes as function arguments. This could be for a few reasons: a) they don’t understand call by reference, b) their functions already have a prohibitive number of arguments, c) they’re code base is highly dependent on their usage of singletons.

    One can argue that some people have never seen a project with 400.000 lines or larger. Trust me on this one, passing references as function arguments is inefficient. You are constantly moving the DB connection as a reference from one function to another, to another, to another. Is that bad? No. Is it nice coding? No. Code what you need, where you need it.

    If you need the ref in function Z, but function Z is located at X -> Y -> Z, your wasting time, and code overview with these constant reference passing. Sure, a registry ref solves that problem if you need to deal with several dbi, param etc, but essentially, your doing the same thing over & over again. Again, code things where you need it. Its a wast of code space, to constantly pass references when you don’t need them, but you “might” need them later on. O wait, function Y did not need the ref, now we need to update function Y, and everywhere function Y is called to include it. Or, your like i said before, forced to constantly keep pasting the reference with all your function, even when they are not needed.

    This discussion to me looks like almost all the MVC discussions i have read. No, thats not real MVC, this is. No, thats wrong, this is. No, your all wrong, that is. *grumbles*

    One of the recurring arguments is: But we need to manage multi different database connections bla bla bla … No you don’t. Is it so hard to create a singleton for mysql, and one of oracle? Or equip your singleton to deal with multi connection types. There are lots of examples out there on the net ( some bad, some excellent ).

    It looks like people are going overboard in a rabbit war, over no good reason. Sure, global declarations are something to be avoided if possible, but lets face it. If you need your Database connection at Z, you are not going to wast time, reconnection the connection every! time. So, you initial the DB connection as a singleton, or use a reference, or use a global ( a ref registry is the same as a ref dbi, no mather how you dress it up ). Thats it. The singleton in my eyes, saves code that you don’t need to write again, again. A proper implementation of a singleton prevents it from getting altered in a improper way.

    Don’t underestimate the mess that can be created with a passing a ref all over the place. Seen it before. The arguments that can be used to put down a singleton, can in a lot of cases also be used against the other methods.

    KISS people, KISS. The proper tool for the job. Unless there is a specific performance, bugs, or other problematic things around them, there is no reason to avoid singleton usage. A good implemented singleton is a good solution. All the rest is just people wanting to push there definition of “good” programming on each other. Just like almost any MVC thread where everybody has there own definition of “good” MVC.