3 The Principles of Sound Structure: From Code That Works to Code That Lasts
This chapter shifts the focus from making good decisions to building good structures: code that not only works today, but remains understandable, adaptable, and safe to change over time. The central message is that maintainability comes from writing for the reader, not the writer, and from organizing software so each part has a clear purpose. Instead of tangled “junk drawer” code, the goal is a well-organized toolbox made of focused, predictable pieces.
To get there, the chapter explains separation of concerns, cohesion, and coupling as the basic ways to judge structure. High cohesion means a module’s contents belong together and serve one clear purpose; loose coupling means modules depend on each other as little as possible. These ideas are reinforced through analogies like LEGOs versus super-glued bricks, and through a coupling test that asks whether interactions between classes feel like a simple conversation or a deep interrogation. The chapter also shows how encapsulation and functional habits such as pure functions and immutability help reduce hidden side effects and keep the “blast radius” of change small.
The SOLID principles then act as a practical checklist for applying these ideas in object-oriented design. Single Responsibility keeps each class focused, Open/Closed encourages extension without risky modification, Liskov Substitution ensures subclasses behave as valid replacements, Interface Segregation avoids fat interfaces, and Dependency Inversion keeps high-level code dependent on abstractions rather than concrete details. Through refactoring examples, including a monolithic order processor and a duplicated “Hydra” scorecard system, the chapter shows how small, defensible design choices improve testability, reliability, and long-term flexibility, while the deeper lesson is that good architecture emerges from many consistent decisions at every scale.
Look to create toolboxes, not junk drawers!
Understanding High vs. Low Cohesion and Loose vs. Tight Coupling.
The Midfielder should have one responsibility as a player, not also be coach and physio!
The Open/Closed Principle (OCP). The player's core job is closed for modification, but their playbook is open for extension. In code, the playbook is the shared contract, and the new plays are the new Classes.
Bob gets a red card for trying to play goalie when he is a midfielder after lying to the coach.
Players should train only in the areas required for their position!
Dependency Inversion Principle (DIP). By depending on the abstract contract (the playbook role) rather than the concrete Forward class (the specific person), the system becomes loosely coupled and easy to change.
Refactoring the OrderProcessor into multiple pieces maintains proper Separation of Concerns.
Archie taking on and defeating the 35-headed Hydra!
Composability allows components to be assembled in various combinations.
The fractal nature of architecture on display.
Simula ushered in the dawn of Object-Oriented Programming concepts.
Time to perform a structural audit on your code!
Recap
- Separation of Concerns is the foundation of good structure; it's the difference between a chaotic "junk drawer" and a well-organized "toolbox."
- The goal is to create components with High Cohesion (where internal parts are strongly related) and Loose Coupling (where components connect like LEGOs, without depending on each other's internal details).
- The SOLID principles are a "pre-flight checklist" for creating code that is easier to maintain, test, and change over time.
- Single Responsibility: A class should have one reason to change.
- Open/Closed: Extend behavior by adding new code, not modifying old code.
- Liskov Substitution: Child classes must be true substitutes for their parent class.
- Interface Segregation: Interfaces should be small and specific, not "fat."
- Dependency Inversion: Depend on abstractions, not concrete details
- Using abstractions and shared contracts (such as interfaces or abstract classes) is the primary way to build flexible systems that are open to extension and easy to test.
- A key goal of good architecture is to minimize the "blast radius," ensuring that a change or failure in one area doesn't cause a catastrophic failure in another.
- Great architecture isn't about one massive design decision, but the consistent application of these principles through many small, good decisions made daily.
- Architectural principles are fractal. The same ideas apply from a single method up to the entire system.
FAQ
What is Separation of Concerns (SoC) in software architecture?
Separation of Concerns means each piece of code should do one thing and do it well. The goal is to keep database logic, UI logic, and business rules in separate areas so the system is easier to understand, test, and change.
How can I tell if a class has low cohesion?
A class has low cohesion when its methods and responsibilities do not fit together around a single purpose. If one class handles unrelated jobs like authentication, logging, and currency formatting, it likely has low cohesion.
What does tight coupling look like in code?
Tight coupling happens when one module depends too heavily on another, so changing one forces changes in many others. A sign of tight coupling is when a client makes many low-level calls or must know the internal structure of another class.
What is the “Simple Conversation Test” for coupling?
The Simple Conversation Test asks whether two classes interact through a few clear, high-level calls or through a long interrogation of small method calls. If the interaction feels like a deep back-and-forth sequence, that is usually a sign of tight coupling.
How does the Single Responsibility Principle (SRP) improve design?
SRP says a class should have only one reason to change. This improves cohesion, reduces risk, makes testing easier, and keeps changes from spreading across unrelated parts of the codebase.
What problem does the Open/Closed Principle (OCP) solve?
OCP helps you add new behavior without changing stable, working code. Instead of modifying existing classes with more if/else logic, you extend the system by adding new classes that follow a shared contract.
Why is the Liskov Substitution Principle (LSP) important?
LSP ensures that a child class can replace its parent class without surprising the rest of the application. If a subclass breaks the expected behavior of the parent, the design becomes deceptive and unreliable.
What is Interface Segregation Principle (ISP) and why does it matter?
ISP says classes should not be forced to depend on methods they do not use. Small, focused interfaces reduce unnecessary coupling and prevent “fat” interfaces that create confusing placeholder methods and runtime errors.
What does the Dependency Inversion Principle (DIP) mean?
DIP says high-level modules should depend on abstractions, not concrete implementations. This makes systems more flexible, easier to test, and safer to change because the business logic is not welded to specific low-level details.
Why do architects focus on reducing “blast radius”?
Blast radius is how far a defect or change spreads through the system. Good architecture minimizes blast radius by creating clear boundaries and reducing dependencies, so a change or bug stays contained in one part of the code.
Grokking Software Architecture ebook for free
