Slides from my talk at DDD SW4

1. Principles behind good software design
IS YOUR CODE SOLID?
nathangloyn
@NathanGloyn
Design Code Release
nathan@gloyn.co.uk

2. Agenda
 The origin of S.O.L.I.D
 What is S.O.L.I.D?
 Design Smells
 The principles
 S.O.L.I.D code is...
 Summary
 Questions
 Resources

3. The origin of S.O.L.I.D
Who is this man?

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

6. Design Smells
 Rigidity
 Fragility
 Immobility
 Viscosity
 Needless Complexity
 Needless Repetition
 Opacity

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

9. The principles
Single Responsibility Principle
Code

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

11. The principles
Interface Segregation Principle
Code

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

13. The principles
Dependency Inversion Principle
Policy Layer
Mechanism Layer
Utility Layer

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

17. The principles
Dependency Inversion Principle
Code

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

19. The principles
Open/closed Principle
Code

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

22. The principles
Liskov Substitution Principle
Fail

23. The principles
Liskov Substitution Principle
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

25. S.O.L.I.D code is...
 Loosely coupled
 Highly cohesive
 Easy to evolve/change
 Testable

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

27. Questions?

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