Simple Design

Origin

Authoritative

Extreme Programming Explained, 1st edition, page 57

Simple Design

The right design for the software at any given time is the one that

  1. Runs all the tests.
  2. Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies.
  3. States every intention important to the programmers.
  4. Has the fewest possible classes and methods.

…take out any design element that you can without violating rules 1, 2, and 3.

Accessible

Fowler

I express them like this.

  • Passes the tests
  • Reveals intention
  • No duplication
  • Fewest elements

The rules are in priority order, so “passes the tests” takes priority over “reveals intention”

Versions

C2

Simple code:

  1. Passes all the tests.
  2. Expresses every idea that we need to express.
  3. Says everything OnceAndOnlyOnce.
  4. Has no superfluous parts.

…Alternative list:

  1. Runs all the tests.
  2. Maximizes Cohesion
  3. Minimizes Coupling
  4. Says everything OnceAndOnlyOnce.

Jeffries

  1. The system is highly modular, consisting of separate components (typically objects) which are highly cohesive and loosely coupled.
  2. The modular components are given expressive names, which enable us to grasp quickly what the modules mean, and why they are there.

…Some time ago, Kent Beck offered the following “rules” for simple design. In priority order, the code must:

  1. Run all the tests
  2. Contain no duplicate code
  3. Express all the ideas the author wants to express
  4. Minimize classes and methods

…In a posting on the Agile Modeling mailing list, Alan Shalloway of Net Objectives, proposed some alternative rules:

  1. Runs all the tests
  2. Follows once and only once rule (which I believe means “contains no duplicate code”)
  3. Has high cohesion (clarity)
  4. Has loose coupling