Component design

Getting cohesion and coupling right


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


http://bit.ly/component-design

What are components?

They are kinda like boxes

Except that they do stuff

What are components?

Benefits of components

Separation of concerns

Reusability

Encapsulation

Substitutability

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



http://bit.ly/component-design