Software Modularity

Why?

Decision Hiding

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.

β€” Robert C. Martin, The Single Responsibility Principle

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

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