The SOLID Principles Illustrated by Design Patterns

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

Transcript of The SOLID Principles Illustrated by Design Patterns

The SOLID PrinciplesIllustrated by Design Patterns

Hayim Makabeehttp://EffectiveSoftwareDesign.com

About Me:Education:

Experience:

Current:

The SOLID PrinciplesSingle Responsibility principleOpen/Closed principleLiskov Substitution principleInterface Segregation principleDependency Inversion principle

Strategy Design Pattern

Single Responsibility PrincipleEach class should have a single

responsibility. Only one potential change in the system's specification should affect the implementation of the class.

Single Responsibility @ Strategy

The responsibility for the implementation of a concrete strategy is decoupled from the context that uses this strategy.

Open/Closed Principle“Software entities (classes,

modules, functions, etc.) should be open for extension, but closed for modification.” - Bertrand Meyer

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.

Liskov Substitution PrincipleObjects in a program should be

replaceable with instances of their subtypes without altering the correctness of that program.

Liskov Substitution @ Strategy

All concrete strategies implement the same interface and should be substitutable without affecting the system’s correctness.

Interface Segregation PrincipleNo client should be forced to

depend on methods it does not use. Many client-specific interfaces are better than one general-purpose interface.

Interface Segregation @ Strategy

Concrete strategies implement an interface that provides only the specific needs of the context that uses it.

Dependency Inversion PrincipleHigh-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.

Dependency Inversion @ Strategy

Both the context and the concrete strategies depend on an abstract interface and are not directly coupled.

Visitor Design Pattern

Visitor: Sequence Diagram

Is Visitor SOLID?Visitor violates the Single-

Responsibility principle. Consequence = weak cohesion.

Visitor

V1 V2 V3

Element

E1 E2 E3

The Problem with VisitorWhen a new Element is added,

all Visitors must be changed to add a new method.

Visitor

V1 V2 V3

Element

E1 E2 E3 E4

Single ResponsibilityIdeally: 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)

Limitation of Single DispatchIn 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)

Singleton Design Patternpublic class Singleton { private static final Singleton

INSTANCE = new Singleton();private Singleton() {}

public static Singleton getInstance() {

return INSTANCE; }

}

The Problem with SingletonSingleton causes strong coupling:

S

m1 m2 m3 m4

XSXOXLXIXD

Refactoring the Singleton – Step 1Pass the Singleton object as a

parameter:S

m1 m2 m3 m4S S S

VSXOXLXIXD

Refactoring the Singleton – Step 2Derive the Singleton from an

Interface:

S

m1 m2 m3 m4I I I

I VSXOXLVIVD

Refactoring the Singleton – Step 3Several concrete Singleton

classes:

S1

m1 m2 m3 m4I I I

I

S2

VSXOVLVIVD

Refactoring the Singleton – Step 4Parameter-based Singleton

“selector”:

S1

m1 m2 m3 m4I I I

I

S2

Selector VSVOVLVIVD

Factory Design Pattern

Pattern MetamorphosisThrough 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…

ConclusionsTo 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.

Thanks!

Q&A

http://EffectiveSoftwareDesign.com