Robert C. Martin (Uncle Bob): the house authority for structure
Robert C. Martin (Uncle Bob): the house authority for structure
Appendix C
•
Appendix
•
3
min read
Robert C. Martin (Uncle Bob) — the house authority for structure
Where Fowler supplies the catalogue, Robert C. Martin supplies the principles that decide how the food-delivery service is wired together: which way the dependencies point, why CourierMatchingStrategy is an interface and not a switch, and why the order domain never imports the payment SDK directly.
Martin, Robert C.Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2008. The naming and function-size discipline behind every snippet in the book. https://blog.cleancoder.com
Martin, Robert C.Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall, 2017. The dependency-rule lineage behind the Ports & Adapters form the book teaches: the order domain at the centre, payment and courier providers at the edges.
Martin, Robert C.Agile Software Development: Principles, Patterns, and Practices. Prentice Hall, 2002. The original full statement of the SOLID principles.
The SOLID principles — Robert C. Martin.
- S — Single Responsibility. Why OrderGateway owns SQL and nothing else. - O — Open/Closed. Why a new courier-matching rule is a new CourierMatchingStrategy, not an edit to the matcher. - L — Liskov Substitution. Every payment Adapter honours the same contract. - I — Interface Segregation. The courier app's BFF does not depend on the restaurant's menu-edit methods. - D — Dependency Inversion. The DI anchor: the order service depends on an IPaymentGateway abstraction, not on a concrete provider. Pairs with Fowler's DI article above.
Altitude 1 — Object
Most of the patterns at this altitude come from a single source: Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John.Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. ISBN 0-201-63361-2. The "Gang of Four" (GoF). The original object-level catalogue of 23 patterns. Two more reach just past it, Fowler's Money and Woolf's Null Object, each cited below.
Strategy, Adapter, Decorator, Command, State, Proxy, Composite — the curated seven, all from the original GoF catalogue. In the food-delivery app: the order lifecycle is State; courier-matching is Strategy; the payment provider is an Adapter; surge/promo/loyalty pricing stacks as Decorator; place/cancel/add-to-cart are Command; lazy-loaded menu images are a Proxy; and the menu (sections → items → modifier-groups → modifiers) is the Composite.
Factory Method, Facade, Template Method, Chain of Responsibility — honorable mentions, also GoF.
Money — Fowler, Patterns of Enterprise Application Architecture (PoEAA), 2002; the Money pattern, a Value Object. https://martinfowler.com/eaaCatalog/money.html Prices, surge, promo, and the payment charge all carry an amount and its currency as one immutable value, with rounding owned in a single place.
Null Object — Bobby Woolf, "Null Object," in Pattern Languages of Program Design 3, Addison-Wesley, 1998; see also Fowler, Refactoring (Introduce Special Case). A degenerate Strategy whose algorithm is "do nothing": the silent NullNotifier handed to a customer who opted out of notifications.
Singleton — GoF. Taught only as the over-engineering skip (global state; prefer DI lifetimes). The common critique is Miško Hevery, "Singletons are Pathological Liars," http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
The language-absorbed patterns — Observer (now C# event / IObservable<T>, or a WebSocket pushing live order updates to the customer), Iterator (now IEnumerable<T> / yield), and Builder (now object/collection initialisers and with expressions) are GoF patterns the C# language absorbed. We don't teach what the compiler gives you.