2

I'm reading the Design patterns book by the Gang of 4. Does a singleton use encapsulation? To me it would seem like yes, but i'm not 100% sure. Maybe I don't have a good understanding of encapsulation.

  • The class that the singleton makes into a single instance (if it is properly designed) uses encapsulation. – Robert Harvey Sep 26 '16 at 0:13
  • can you elaborate? How would I know if I violated encapsulation? – PartOfTheOhana Sep 26 '16 at 0:14
  • In other words, the Singleton doesn't affect how well (or how poorly) your class being singleton'd observes encapsulation. The only thing a Singleton class (or the Singleton code placed into a class) sdoes is limit you to a single class instance. It doesn't affect your overall encapsulation, except that you won't have to worry about multiple instances encapsulating separate state sets, but only one instance. – Robert Harvey Sep 26 '16 at 0:17
  • 4
    To put it another way, if your class has crappy encapsulation, it will still have crappy encapsulation after you turn it into a Singleton. – Robert Harvey Sep 26 '16 at 0:18
6

I'm not aware of a commonly agreed upon canonical definition of “encapsulation” but I believe that we can require at least the following.

An object's internals are encapsulated if it is not possible to transform the object into an invalid state (where its invariants are broken) via its public interface.

The public interface of the singleton class consists of a single static function getInstance plus whatever interface the singleton object actually provides (this is not part of the pattern). The getInstance function clearly cannot be used to bring anything in an invalid state because all it does is creating an instance via the default constructor and caching it in a global variable. Whether the actual (useful) interface of the class obeys encapsulation is up to its implementer. (Because the default constructor is private, it would in principle be allowed to construct an object in an invalid state but let's assume it doesn't.)

Considering the encapsulation of the rest of the class, the singleton pattern doesn't change anything about it. Or, as Robert Harvey has put it in the comments:

A Singleton doesn't bring any encapsulation to the table that a class doesn't already have. If a class has poor encapsulation, it will still have poor encapsulation after it is turned into a Singleton. A Singleton restricts a class to a single instance, and that's all that it does.

On the other hand, if your class was properly encapsulated in the first place, making it a singleton will not destroy that property. The singleton pattern violates another important principle, though. The single responsibility principle. It basically says that each component should do one job and do it well. (See the comments below for a somewhat different opinion.) The singleton pattern couples the business logic the class performs together with the rules who may create an instance of it and how many. This leads to tighter coupling between it and its consumers than desirable and makes especially testing needlessly hard. Nowadays the singleton is considered an antipattern by many. Much has been said about it so here is only one video from Google's Clean Code Talks on the topic: “Global State and Singletons” by Miško Hevery.

  • 1
    Per your last point: I am not convinced that singletons violate SRP. Most importantly, they are thinly-veiled global variables. – user22815 Sep 26 '16 at 0:17
  • 2 things - 1 - if the constructor made the object in a valid state, would it utilize encapsulation? 2 - the clean code talks series is great! I wasn't aware of that until now. are there similar resources i should be aware of? – PartOfTheOhana Sep 26 '16 at 0:17
  • 2
    @user11235813: I'm afraid you're missing the point. A Singleton doesn't bring any encapsulation to the table that a class doesn't already have. If a class has poor encapsulation, it will still have poor encapsulation after it is turned into a Singleton. A Singleton restricts a class to a single instance, and that's all that it does. – Robert Harvey Sep 26 '16 at 0:25
  • @Snowman Yes, it's basically a global variable except you only have mediated access to it. I've re-worded the sentence about the “primary reason” if that is less evident than I thought. How (if not as an SRP issue) would you characterize the problem that the class itself manages its instantiation and life-time? Or do you think that that's not an issue actually? – 5gon12eder Sep 26 '16 at 1:19
  • @5gon12eder Classes have constructors which manage instantiation, so I have always found a class that is its own factory to be a weak argument that it violates SRP. Which, by the way, is about change and not what an object does, and is aimed at the method level, not the object/class level. In most languages, "singleton" is not about lifecycle management anyway, because modern languages do not have explicit memory management and the class that creates the one instance does not destroy it. – user22815 Sep 26 '16 at 1:23

protected by user22815 Sep 26 '16 at 23:48

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.