Getting cohesion and coupling right
Created by
Jeroen De Dauw
for Wikimedia Deutschland
Licensed CC BY-SA 3.0
They are kinda like boxes
Except that they do stuff
Separation of concerns
Reusability
Encapsulation
Substitutability
Independently deployable
Independently developable
Divide and conquer
Which classes should go together in a component?
→ Principles of package cohesion
How should components relate to each other?
→ Principles of package coupling
Aim: make development and usage as painless as possible
How should components relate to each other?
Directed acyclic graph
Depend in the direction of stability
Very stable ➜ somewhat stable ➜ unstable
Unstable ➜ somewhat stable ➜ very stable
A package should be as abstract as it is stable
Allows us to satisfy SDP while depending on abstractions and retaining changeability
Abstract = # abstract classes / # classes
Stable = # dependents / # components
Which classes should go together in a component?
In order to be reused, a component must be released
Granule of release is granule of reuse
Either all reusable or not reusable
Classes that change for the same reason should be in the same component
Changes should not span packages, and affect everything in the package
Classes that are used together should be in the same component
If you use one class from a package, you depend on them all
Like ISP
Interplay of the forces
Evolution of components
Components in a layered system
Recommended reading