Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why Every Element of SOLID is Wrong

Why Every Element of SOLID is Wrong

Five minute Ignite-style talk from PubConf London 2016

Daniel Terhorst-North

January 20, 2017
Tweet

More Decks by Daniel Terhorst-North

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. Open-Closed Principle Open for extension, closed for modification “When requirements

    change,
 extend behaviour by adding new code,
 not changing code that works”
  4. 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
  5. 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!
  6. Liskov Substitution Principle “Strong behavioural subtyping” Substitution with a subtype

    preserves all
 “desirable properties” of the original type “Provably undecidable” but useful
  7. 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
  8. 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!
  9. 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
  10. 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!! —>
  11. 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!
  12. 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)
  13. Dependency Inversion Principle Reuse is overrated, design for use! DIP

    leads to a different kind of dependency,
 dependency on DI frameworks! Wrong Goal Principle
  14. 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!