Reflective Design

Audience

Programmers

Every day, our code is better than it was the day before.

Traditional approaches to design assume code shouldn’t change. Instead, new features and capabilities are supported by adding new code. A traditional design supports this by anticipating what might be needed and building in extensibility “hooks,” in the form of inheritance, dependency injection, and so forth, so code for those features can be added in the future. The Open-Closed Principle, a classic design guideline, illustrates this mindset: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

Allies

Simple Design

Refactoring

But Agile teams create simple designs that don’t anticipate the future. Their designs don’t have hooks. Instead, Agile teams have the ability to refactor their code and change its design. This creates the opportunity for an entirely different approach to design: one in which entities are not designed to be extended, but are designed to be modified instead.

I call this approach reflective design.

...to continue reading, buy the book!

In this Section

1. Reflective Design
   1. How Reflective Design Works
   2. Reflective Design in Practice
   3. Reverse-Engineering the Design
   4. Identifying Improvements
   5. Code Smells
      1. Shotgun Surgery and Divergent Change
      2. Primitive Obsession and Data Clumps
      3. Data Class and Code Class
      4. Squashed Errors and Coddled Nulls
      5. Time Dependencies and Half-Baked Objects
   6. Incrementally Refactor
      1. Sidebar: A Reflective Design Étude
   7. Questions
   8. Prerequisites
   9. Indicators
   10. Alternatives and Experiments
   11. Further Reading