The Perks and Perils of the Singleton Design Pattern
0 likes•148 views
The document discusses the singleton design pattern, emphasizing its purpose to ensure a single instance of an object that can be globally accessed, alongside its benefits like simplified object access and self-creation logic. It also explores the drawbacks, labeling it as an anti-pattern due to issues such as global variable behavior, difficulty in unit testing, and increased coupling among classes. Alternatives like dependency injection are suggested to mitigate the negative impacts associated with overusing singletons.
![Solution
Head up to that class, and:
â—Ź Restrict the class to create only one object
â—Ź Provide global access to it
Ref: [1]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-4-320.jpg)
![Techniques
Lazy initialization
Ref: [2]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-8-320.jpg)
![Techniques 2
Synchronized lazy initialization
Clearer, but lower concurrency
Higher concurrency
Ref: [2]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-9-320.jpg)
![Techniques - 3
Eager initialization
No need for synchronization
Ref: [2]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-10-320.jpg)
![Singleton as an anti-pattern
Singleton is popular because:
â—Ź It was included in GoF Design Patterns
● It’s easy; the easiest in the book
People started a rebellion:
â—Ź Any design pattern can be abused, except for Singleton
â—Ź Valid motive, but ruins everything with its two steps
Ref: [3, 10]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-13-320.jpg)
![Glorified Global Variables
Have a bug? Now go over all those files for a clue!
Mutable
state
1
This one
caused the
bug
2
This one
found it
Ref: [4]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-14-320.jpg)
![Glorified Global Variables
When some code uses a global variable, it’s harder to
reason about it
Mutable
state
1
To know what this
object / function is
doing
2
You also
need to
understand
what this is
doing
Ref: [4]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-15-320.jpg)
![Lifecycle
The Singleton controls its own creation and lifecycle
â—Ź Violation of SRP:
â—‹ Connecting to database is a responsibility
â—‹ Creating, opening and closing the connection are other
responsibilities
â—Ź Resetting the state is harder and more error-prone
than creating a new object
Ref: [3, 5]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-16-320.jpg)
![Lifecycle
● The user’s signed-in session is shorter than the
application’s lifecycle.
â—Ź A global state, if necessary, should only handle states
that last for the entire application’s complete lifecycle
Ref: [5]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-18-320.jpg)
![Hiding Dependencies
● You don’t know what that Singleton needs
○ Singleton.getInstance() doesn’t explain much
Data List Singleton
What you see
Data List Singleton
What it actually is
Connection Authenticator
User
Ref: [3]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-19-320.jpg)
![Hiding Dependencies - Example
â—Ź Only works when you run as
part of the suite.
â—Ź When run in isolation,
throws
NullPointerException.
Ref: [3]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-20-320.jpg)
![Hiding Dependencies - Example
â—Ź You ask a senior, and he tells
you that CreditCardProcessor
needs to be handled first
â—Ź Still, it throws an exception
Ref: [3]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-21-320.jpg)
![Hiding Dependencies - Example
â—Ź You ask more. Now you know
that both Database and
OfflineQueue need to be
initialized first
â—Ź The code worked!
â—Ź Now your bank account only
has $12.5 because this code
charged you for $100
Must be done
in the same
order!
Ref: [3]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-22-320.jpg)
![â—Ź The code is not stable, if Database gets modified,
other classes may fail
○ Because you don’t know what depends on Database and how
â—Ź The code is not flexible, anything that depends on a
Singleton is hard wired to that Singleton
● You can’t unit test a class without the Singleton
initialized
● You can’t use mock objects for testing
Hiding Dependencies
Ref: [3]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-23-320.jpg)
![Encourage Coupling
● Since it’s global, any class anywhere can get it easily
â—Ź If the developer is thinking hard how to get it in that
class, he would think if that class should get it
Coupling between SomeTransaction
and MySQLConnection
Ref: [4]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-24-320.jpg)
![The Root of the Problem
This part is
very
legitimate!
This is
not
Ref: [9]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-29-320.jpg)
![Solution
● Pass it a.k.a “Inject it!”
â—Ź Get it from somewhere already global
â—‹ That place is responsible for creating it and managing its
lifecycle
â—‹ There are some evils that we can only reduce, but can never
eliminate, like global state
Ref: [7]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-30-320.jpg)
![Example
A whole bunch of singletons
Ref: [7]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-31-320.jpg)
![Example
new OfflineQueue(database)
Ref: [7]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-32-320.jpg)
![Example
● We’re sure that only one object is being used
â—Ź Dependencies are declared
â—Ź Dependencies are passed
â—Ź Each class is testable and mockable
● “Creation” is the factory’s responsibility
● If you ever need to have a new database, you don’t
have to modify available classes
Ref: [7]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-33-320.jpg)
![Immutable State Singletons
Immutable state Singletons, enums in Java, objects in
Scala, … are okay
But still, be aware of coupling, limiting classes from
inheritance, hiding dependencies …
Ref: [9]](https://image.slidesharecdn.com/designpatterns-singleton-161229133124/85/The-Perks-and-Perils-of-the-Singleton-Design-Pattern-34-320.jpg)
The Perks and Perils of the Singleton Design Pattern
- 2. Singleton The Perks and Perils of the Singleton Design Pattern
- 3. Motivation You have that one, and exactly one object: ● Database connection ● Hardware interface ● … and you have to make sure all parts of the application use that one and only object
- 4. Solution Head up to that class, and: â—Ź Restrict the class to create only one object â—Ź Provide global access to it Ref: [1]
- 5. Example Single Instance Global Access Use it anywhere
- 6. View 1 View 2 Users Store Some object Example - Diagram
- 7. Example - Even more! View 1 View 2 View 3 Users Store Departments Store Singletons (DB / Backend) Connection
- 9. Techniques 2 Synchronized lazy initialization Clearer, but lower concurrency Higher concurrency Ref: [2]
- 10. Techniques - 3 Eager initialization No need for synchronization Ref: [2]
- 11. Benefits ● State shared globally as required ● Global access; No complications to object access ● The object handles its own creation logic ● Hide details of the Singleton ● Can be used to implement some other patterns as well ○ Abstract Factory, Builder, Prototype …
- 13. Singleton as an anti-pattern Singleton is popular because: ● It was included in GoF Design Patterns ● It’s easy; the easiest in the book People started a rebellion: ● Any design pattern can be abused, except for Singleton ● Valid motive, but ruins everything with its two steps Ref: [3, 10]
- 14. Glorified Global Variables Have a bug? Now go over all those files for a clue! Mutable state 1 This one caused the bug 2 This one found it Ref: [4]
- 15. Glorified Global Variables When some code uses a global variable, it’s harder to reason about it Mutable state 1 To know what this object / function is doing 2 You also need to understand what this is doing Ref: [4]
- 16. Lifecycle The Singleton controls its own creation and lifecycle â—Ź Violation of SRP: â—‹ Connecting to database is a responsibility â—‹ Creating, opening and closing the connection are other responsibilities â—Ź Resetting the state is harder and more error-prone than creating a new object Ref: [3, 5]
- 17. Lifecycle â—Ź Now you have to make all Singletons reset to initial state â—Ź You have to wait to reset properly â—‹ Sync data â—‹ Clear cache
- 18. Lifecycle ● The user’s signed-in session is shorter than the application’s lifecycle. ● A global state, if necessary, should only handle states that last for the entire application’s complete lifecycle Ref: [5]
- 19. Hiding Dependencies ● You don’t know what that Singleton needs ○ Singleton.getInstance() doesn’t explain much Data List Singleton What you see Data List Singleton What it actually is Connection Authenticator User Ref: [3]
- 20. Hiding Dependencies - Example â—Ź Only works when you run as part of the suite. â—Ź When run in isolation, throws NullPointerException. Ref: [3]
- 21. Hiding Dependencies - Example â—Ź You ask a senior, and he tells you that CreditCardProcessor needs to be handled first â—Ź Still, it throws an exception Ref: [3]
- 22. Hiding Dependencies - Example â—Ź You ask more. Now you know that both Database and OfflineQueue need to be initialized first â—Ź The code worked! â—Ź Now your bank account only has $12.5 because this code charged you for $100 Must be done in the same order! Ref: [3]
- 23. ● The code is not stable, if Database gets modified, other classes may fail ○ Because you don’t know what depends on Database and how ● The code is not flexible, anything that depends on a Singleton is hard wired to that Singleton ● You can’t unit test a class without the Singleton initialized ● You can’t use mock objects for testing Hiding Dependencies Ref: [3]
- 24. Encourage Coupling ● Since it’s global, any class anywhere can get it easily ● If the developer is thinking hard how to get it in that class, he would think if that class should get it Coupling between SomeTransaction and MySQLConnection Ref: [4]
- 25. Encourage Coupling â—Ź Now, you need to use a NoSQL database along with the SQL one â—Ź SomeTransaction should switch to NoSQL database SomeTransaction MongoDBConnection MySQLConnectionTightly coupled Remove the coupling between SomeTransaction and MySQLConnection first
- 26. Limiting Instantiation Are you really sure you won’t need another object of that Singleton class? nobacks.com SingletonScreen We only need one object for that one screen nobacks.com So what happens when I plug that screen to the laptop?
- 27. Big deal! I don’t care if they’re bad or not. I only use one or two Singletons, what’s going to happen anyway? Source
- 28. That’s the real problem! This one or two Singletons are strangling all or most of classes ○ Many classes are tightly coupled to it ○ Many classes can’t be tested properly ○ Change something in that Singleton and all other classes need to be changed as well
- 29. The Root of the Problem This part is very legitimate! This is not Ref: [9]
- 30. Solution ● Pass it a.k.a “Inject it!” ● Get it from somewhere already global ○ That place is responsible for creating it and managing its lifecycle ○ There are some evils that we can only reduce, but can never eliminate, like global state Ref: [7]
- 31. Example A whole bunch of singletons Ref: [7]
- 33. Example ● We’re sure that only one object is being used ● Dependencies are declared ● Dependencies are passed ● Each class is testable and mockable ● “Creation” is the factory’s responsibility ● If you ever need to have a new database, you don’t have to modify available classes Ref: [7]
- 34. Immutable State Singletons Immutable state Singletons, enums in Java, objects in Scala, … are okay But still, be aware of coupling, limiting classes from inheritance, hiding dependencies … Ref: [9]
- 35. References 1. c2.com: Singleton 2. Wikipedia 3. SO: What's so bad about singletons 4. gameprogrammingpatterns.com 5. Avoiding Singleton Abuse 6. programmers.stackexchange: So singletons are bad then what 7. Singletons are pathological liars 8. Where have all the singletons gone 9. Root cause of singletons 10. Singletons considered stupid
- 36. Questions?