Why Every Element of SOLID is Wrong

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!