Component design

Getting cohesion and coupling right

Created by Jeroen De Dauw for Wikimedia Deutschland
Licensed CC BY-SA 3.0

What are components?

They are kinda like boxes

Except that they do stuff

What are components?

Benefits of components

Separation of concerns




Independently deployable

Independently developable

Divide and conquer

Designing components

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

Coupling principles

How should components relate to each other?

Acyclic dependencies principle

Directed acyclic graph

Stable-dependencies principle

Depend in the direction of stability

Very stable ➜ somewhat stable ➜ unstable

Unstable ➜ somewhat stable ➜ very stable

Stable-abstractions principle

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

Cohesion principles

Which classes should go together in a component?

Reuse-release equivalence principle

In order to be reused, a component must be released

Granule of release is granule of reuse

Either all reusable or not reusable

Common-closure principle

Classes that change for the same reason should be in the same component

Changes should not span packages, and affect everything in the package

Common-reuse principle

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

Things not covered

Interplay of the forces

Evolution of components

Components in a layered system

Recommended reading