[tl;dr] Balancing Coupling in Software Design
olano.dev
[tl;dr] Balancing Coupling in Software Design
Vlad Khononov builds on the ideas of Parnas, Myers, Brooks, Conway, and Ousterhout, to produce something new and useful.
The thesis of the book: despite its reputation, coupling is not something fundamentally bad that we need to remove but an attribute that we should manage strategically. Similar to essential complexity, a useful software system can’t exist without some form of coupling of its components. An easy way to internalize this idea is remembering that cohesion is sometimes defined as good coupling.
Software has a fractal nature, one can reason about modularity at the system, service, namespace, class, and function levels. At each level there are interfaces and implementation, module depth and complexity. Complexity is twofold: local and global. And since software is fractal, this level’s global complexity becomes a higher level’s local one. Naively splitting modules into smaller ones just pushes local complexity up, making the overall system more complicated. Our job then is not chasing local minima but striking a balance: a good enough trade-off that reduces total maintenance cost.
Two thirds of the book is spent on definitions: there are the usual suspects (complexity, modularity, coupling), some historically relevant concepts (structured design’s module coupling, connasence), and a few new ones introduced by the author (integration strength, distance, volatility). These are used to compose heuristics (represented as formulas) to assess the modularity and balance of components in a system, to detect problems and hint at possible solutions. This activity is what the author calls balancing (and re-balancing) coupling. The final chapters show concrete applications of these heuristics on a series of case studies.
Stacker News
[tl;dr] Balancing Coupling in Software Design \ stacker news ~Design
The thesis of the book: despite its reputation, coupling is not something fundamentally bad that we need to remove but an attribute that we should ...
