4. The origin of S.O.L.I.D
Principles, Patterns, and Practices
Published in 2002
First book to mention
SOLID
C# edition published 2005
Both books considered
seminal works on SOLID
5. What is S.O.L.I.D?
Principles about class design
To be considered, not rules blindly applied
Made up of acronyms
Minimise design smells
Easier to evolve code
7. The principles
S ingle Responsibility Principle –> SRP
O pen/Closed Principle –> OCP
L iskov Substitution Principle –> LSP
I nterface Segregation Principle –> ISP
D ependency Inversion Principle –> DIP
8. The principles
Single Responsibility Principle
What is the principle?
A class should have only one reason to change.
Why should you use it?
Helps with separation of concerns
Increases cohesion
Reduces coupling
Simplifies the code, making it more readable
Makes future changes easier
10. The principles
Interface Segregation Principle
What is the principle?
Clients should not be forced to depend upon
interfaces that they do not use
Avoid “fat” interfaces
Why should you use it?
Reduces coupling
Implementers only use bits they need.
Helps reduce dependencies
12. The principles
Dependency Inversion Principle
What is the principle?
High-level modules should not depend on low-
level modules. Both should depend on
abstractions.
Abstractions should not depend upon details.
Details should depend upon abstractions.
Don’t call us, we’ll call you
14. The principles
Dependency Inversion Principle
Policy Service
Policy Layer
Interface
Mechanism Service
Mechanism Layer
Interface
Utility Layer
15. The principles
Dependency Inversion Principle
Policy Service Mechanism Service
Policy Layer
Interface Interface
Mechanism Layer
Utility Layer
16. The principles
Dependency Inversion Principle
Why should you use it?
Reduces coupling
Makes it easier to reuse classes
Can make code easier to test
Use IoC to help implement
18. The principles
Open/closed Principle
What is the principle?
Software entities
(classes, modules, functions, etc.) should be open
for extension but closed for modification.
Add new code, don’t touch the old code
Why should you use it?
Systems easier to change/evolve
Reduces risk
Develop and test extensions in isolation
20. The principles
Liskov Substitution Principle
What is the principle?
If for each object o1 of type S there is an object o2
of type T such that for all programs P defined in
terms of T, the behavior of P is unchanged when
o1 is substituted for o2 then S is a subtype of T.
Subtypes must be substitutable for their base
types.
21. The principles
Liskov Substitution Principle
Why should you use it?
Consistent behaviour
Reduces coupling
Makes it easier to evolve code
24. The principles
S ingle Responsibility Principle –> SRP
A class should have only one reason to change.
O pen/Closed Principle –> OCP
Add new code, don’t touch the old code
L iskov Substitution Principle –> LSP
Subtypes must be substitutable for their base types
I nterface Segregation Principle –> ISP
Avoid “fat” interfaces
D ependency Inversion Principle –> DIP
Don’t call us, we’ll call you
26. Summary
Not new, been around a while
Principles not rules
You decide when to apply
It should make it easier to evolve code
Code will be easier to unit test
28. Resources
Principles Of Ood
DimeCasts.Net – screen casts on each principle
Los Techies – series of posts on principles
Hanselminutes – podcast with Uncle Bob
Getting a good SOLID start – post by Uncle bob
Presentation Code – code from the presentation
nathangloyn Design Code Release
@NathanGloyn nathan@gloyn.co.uk