Why Every Element of SOLID is Wrong

Five minute Ignite-style talk from PubConf London 2016

Transcript

1. Why Every Single Element of SOLID is Wrong! Dan North @tastapod
2. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
3. Single Responsibility Principle “one reason to change” “only do one thing”
4. Single Responsibility Principle What is a single responsibility anyway? ETL: three responsibilities or one? How can you predict what is going to change? Pointlessly Vague Principle
5. Single Responsibility Principle Simple code is easy to reason about Can easily do several related things Refactor until it Fits In Your Head Write simple code
6. Open-Closed Principle Open for extension, closed for modification “When requirements change,
 extend behaviour by adding new code,
 not changing code that works”
7. Open-Closed Principle Open for extension, closed for modification “When requirements change,
 the existing code is now wrong!
 so replace it with code that works” Cruft Accretion Principle
8. Open-Closed Principle Simple code is easy to change Simple code is easy to test Simple code is both open and closed Write simple code!
9. Liskov Substitution Principle “Strong behavioural subtyping” Substitution with a subtype preserves all
 “desirable properties” of the original type “Provably undecidable” but useful
10. Liskov Substitution Principle “There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.” Stuck in is-a and has-a modelling mindset Drucker’s Warning Principle
11. Liskov Substitution Principle What about acts-like-a, can-be-used-as-a? Composition is simpler than inheritance Try to avoid object hierarchies altogether Write simple code!
12. Interface Segregation Principle Many small interfaces are better than one big object Design small, role-based interfaces No client depends on methods it doesn’t use
13. Interface Segregation Principle Practically anything is better than one big object Design small, role-based classes No client depends on methods it doesn’t use Stable Door Principle This is already true!! —>
14. Interface Segregation Principle Don’t write big objects in the first place! Write code that Fits In Your Head If a class needs lots of interfaces, simplify the class! Write simple code!
15. Dependency Inversion Principle High-level modules should not depend on
 lower-level modules Abstractions (e.g. interfaces) should not depend on
 details (e.g. concrete implementations)
16. Dependency Inversion Principle Reuse is overrated, design for use! DIP leads to a different kind of dependency,
 dependency on DI frameworks! Wrong Goal Principle
17. Dependency Inversion Principle See how far you get combining simple classes new is the new new! Assemble into small components that Fit In Your Head Write simple code!
18. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
19. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Too much to remember!
20. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Write simple code!