Refactoring to Patterns

many a programmer picks up Design Patterns, gazes at a Structure diagram, and then begins coding. The result is code that exactly mirrors the Structure diagram, instead of a pattern implementation that best matches the need at hand.

A refactoring is a "behavior-preserving transformation" or, as Martin Fowler defines it, "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior"

If you don't know patterns, you're less likely to evolve great designs. Patterns capture wisdom. Reusing that wisdom is extremely useful.

Refactoring helps us do that by focusing our attention on removing duplication, simplifying code, and making code communicate its intention.

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

In general, it's useful to run all of your tests after refactoring to confirm that the code is behaving as you expect.

Once again, test-driven development provides an effective way to reimplement and replace old code.

Evolutionary design provides a better way. It suggests that you:

Form one team

Drive the framework from application needs

Continuously improve applications and the framework by refactoring

Due to ignorance or a commitment to "not fix what ain't broken," many programmers and teams spend little time paying down design debt. As a result, they create a Big Ball of Mud [Foote and Yoder].

Design debt occurs when you don't consistently do three things.

Remove duplication.

Simplify your code.

Clarify you code's intent.