The document discusses the SOLID principles in software design, which includes the Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion principles. It illustrates these principles through various design patterns such as Strategy, Visitor, Singleton, and Factory patterns, highlighting their implementations and potential violations of the SOLID principles. The author emphasizes the importance of understanding and applying these principles to improve software design by reducing coupling and increasing cohesion.

1. The SOLID Principles
Illustrated by Design
Patterns
Hayim Makabee
http://EffectiveSoftwareDesign.com

2. About Me:
Education:
Experience:
Current:

3. The SOLID Principles
 Single Responsibility principle
 Open/Closed principle
 Liskov Substitution principle
 Interface Segregation principle
 Dependency Inversion principle

4. Strategy Design Pattern

5. Single Responsibility Principle
 Each class should have a single
responsibility. Only one potential
change in the system's specification
should affect the implementation of
the class.

6. Single Responsibility @
Strategy
The responsibility for
the implementation
of a concrete
strategy is decoupled
from the context that
uses this strategy.

7. Open/Closed Principle
 “Software entities (classes, modules,
functions, etc.) should be open for
extension, but closed for modification.”
- Bertrand Meyer

8. Open/Closed @ Strategy
The context is open
for extensions and
closed for
modifications since it
does not need to be
changed to use new
types of strategies.

9. Liskov Substitution Principle
 Objects in a program should be
replaceable with instances of their
subtypes without altering the
correctness of that program.

10. Liskov Substitution @
Strategy
All concrete
strategies implement
the same interface
and should be
substitutable without
affecting the
system’s
correctness.

11. Interface Segregation
Principle
 No client should be forced to depend
on methods it does not use. Many
client-specific interfaces are better
than one general-purpose interface.

12. Interface Segregation @
Strategy
Concrete strategies
implement an
interface that
provides only the
specific needs of the
context that uses it.

13. Dependency Inversion
Principle
 High-level modules should not depend
on low-level modules. Both should
depend on abstractions.
 Abstractions should not depend on
details. Details should depend on
abstractions.

14. Dependency Inversion @
Strategy
Both the context and
the concrete
strategies depend on
an abstract interface
and are not directly
coupled.

15. Visitor Design Pattern

16. Visitor: Sequence Diagram

17. Is Visitor SOLID?
 Visitor violates the Single-
Responsibility principle. Consequence
= weak cohesion.
Visitor
V1 V2 V3
Element
E1 E2 E3

18. The Problem with Visitor
 When a new Element is added, all
Visitors must be changed to add a
new method.
Visitor
V1 V2 V3
Element
E1 E2 E3 E4

19. Single Responsibility
 Ideally: Dynamic binding by both type
of Visitor and Element (Double
Dispatch).
Visitor X
Element
E1 E2 E3
V1 m11(v,e) m12(v,e) m13(v,e)
V2 m21(v,e) m22(v,e) m23(v,e)
V3 m31(v,e) m32(v,e) m33(v,e)

20. Limitation of Single Dispatch
 In practice: Dynamic binding only by
type of Visitor, the Element is not
polymorphic.
Visitor X
Element
E1 E2 E3
V1 v.m11(e1) v.m12(e2) v.m13(e3)
V2 v.m21(e1) v.m22(e2) v.m23(e3)
V3 v.m31(e1) v.m32(e2) v.m33(e3)

21. Singleton Design Pattern
public class Singleton {
private static final Singleton
INSTANCE = new Singleton();
private Singleton() {}
public static Singleton
getInstance() {
return INSTANCE;
}
}

22. The Problem with Singleton
 Singleton causes strong coupling:
S
m1 m2 m3 m4
XS
XO
XL
XI
XD

23. Refactoring the Singleton – Step
1
 Pass the Singleton object as a
parameter:
S
m1 m2 m3 m4
S S S
VS
XO
XL
XI
XD

24. Refactoring the Singleton – Step
2
 Derive the Singleton from an Interface:
S
m1 m2 m3 m4
I I I
I VS
XO
XL
VI
VD

25. Refactoring the Singleton – Step
3
 Several concrete Singleton classes:
S1
m1 m2 m3 m4
I I I
I
S2
VS
XO
VL
VI
VD

26. Refactoring the Singleton – Step
4
 Parameter-based Singleton “selector”:
S1
m1 m2 m3 m4
I I I
I
S2
Selector VS
VO
VL
VI
VD

27. Factory Design Pattern

28. Pattern Metamorphosis
 Through the application of the SOLID
principles, we moved from Singleton
to the Factory Design Pattern.
 Singleton is actually a degenerate kind
of Factory that always returns the
same object of the same type…
 The interface of the Factory
(getInstance) is mixed with the
interface of the object itself…

29. Conclusions
 To understand how to apply the
SOLID principles in practice:
1. Choose a Design Pattern.
2. Analyze how this pattern makes use of
the SOLID principles to reduce coupling
and increase cohesion.
 Be aware that some patterns may
violate some of the SOLID
principles.

30. Thanks!
Q&A
http://EffectiveSoftwareDesign.com