Be pragmatic, be SOLID
summary
Explains how to apply the five SOLID principles through concrete refactorings: split an overloaded Employee Active Record into a business model plus a repository/gateway, extract URL validation rules into separate strategy classes for testability, and replace direct PayPal calls with a payment provider interface injected by dependency injection. Demonstrates a Liskov Substitution violation from an overridden add method that throws exceptions and uses design-by-contract to detect it, references Martin Fowler’s cost curves, and warns that testable code can still be poorly designed so apply SOLID pragmatically.
AI-written summary · about
chapters (10)
- 0:00Wprowadzenie do SOLID
- 7:12Kot niezdatny do utrzymania
- 10:46Pojedyncza odpowiedzialność
- 18:49Zasada otwarty-zamknięty
- 23:36Testy a dobry design
- 25:01Zasada podstawienia Liskov
- 32:10Zależności od abstrakcji
- 38:52Segregacja interfejsów
- 41:43Podsumowanie i wartość biznesowa
- 45:00Pytania i odpowiedzi
related talks
39mSeveral years of SOLID-aware development
30mSOLID 101: A Review for Rubyists
41mIs Your Code Too SOLID?
32mDemystifying Design Patterns: A Practical Guide for Developers
37mHonest mistakes caused by shallow interpretation of SOLID
01h 00mSOLID Revisited : The State of the Matter
57mCore Software Design Principles for Programmers
45mBeyond design patterns and principles - writing good OO code