Software Modularity
Why?
Decision Hiding
- Top criterion by Parnas
- everywhere you make a choice about the system implementation, put that choice into a module with an interface that doesnβt expose the choice made
Single Responsibility
When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function.
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
How?
Parnas:
We have tried to demonstrate by these examples that 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.
Architecture Styles
Frameworks, Libraries and Components
- Frameworks are modules, but inversion of control feels wrong
- Libraries can help, to build modular software
- Components are modules, but more restricted with a defined, fixed interface
Software Architektur im Stream β Statt Microservices Framework, Library, Komponenten
Trade-offs
Energy Efficiency
Impacts of Software Modularity on Energy Efficiency
Examples
Linux Pipes
cat access.log | head -n 500 | grep mail | perl -e β¦
Source: Useful Uses of cat
π References
Parnas (1972). On the Criteria to be Used in Decomposing Systems into Modules