Why Every Element of SOLID is Wrong

Why Every Element of SOLID is Wrong

Five minute Ignite-style talk from PubConf London 2016

08145ecb1ce091d9dd3c328ea2a707fb?s=128

Daniel Terhorst-North

January 20, 2017
Tweet

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!