David Parnas wrote:... it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
What I've read in the book sample and Juval's answers so far does seem to align to the above proposal, to base design decisions on what's likely to change (what Juval refers to as Volatility-based Decomposition).
I'd like to get some feedback on my current understanding, which admittedly is still very fuzzy, about all this. Drawing from what I know and what I've experienced in the past, it seems to me these ideas are related to DRY (Don't Repeat Yourself) and the Single Responsibility Principle (that a software module should have one and only one reason to change). One of the criticisms of functional decomposition is that you often end up duplicating the same kind of functionality or "knowledge" across multiple modules. This is a violation of DRY which states that "In a system, there should be one and only representation of each piece of knowledge."
Juval, am I (even somewhat) on the right track here? There are still a lot of other questions I'd like to ask but it seems to me the above is fundamental to correctly understanding yours and Parnas' ideas about modularization and decomposition.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
While DRI and SRP are good ideas, they are secondary if not tertiary to the main idea of encapsulating change.
As you will see in Chapter 3, where the book offers structure and guidelines, a single component could even encapsulate multiple volatilities.
So the dominant idea, the main added value is the encapsulation, not the singularity of it.
What you are missing in the picture is the role of components, a governing taxonomy.
I hope that once you read Chapter 3 (and Chapter 4) it will become clear.