Thread by @jbrains

I can answer the questions from my talk at @jaxcon today. There were only two.

@jaxcon "Can you recommend a book on evolutionary design?"

I can recommend a few. You can probably feel comfortable starting with any of them.

- Beck, _Test-Driven Development: By Example_
- Koskela, _Test-Driven_
- Jeffries, _Extreme Programming Adventures in C#_

Even my own book, _JUnit Recipes_, has content on evolutionary design. I had agreed with the publisher _not_ to write a book about #tdd, but rather about how to use #junit, but in those recipes you will find some parts that start "...and if you're doing TDD, then you will...".

Of course, I also need to promote my own training course, "The World's Best Intro to TDD: Level 1", where I show examples of how to guide the evolution of design using tests.

tdd.training

But especially I wish to draw attention to two wonderful books that help deeply understand how to guide designs to evolve:

- Freeman & Pryce, _Growing Object-Oriented Software Guided by Tests_
- Fowler, _Refactoring_

Next question...

"Is evolutionary design compatible with a plugin architecture? What happens when clients can write their own plugins?"

I will interpret this question as "how can we safely guide the design to evolve when we must publish some APIs to the general public?"

Summary: Yes.

Details: When testing code in isolation, it usually becomes convenient to inject dependencies. When removing duplication, it frequently happens that I see common workflows. These two forces combine to push the design the direction of the Template Method pattern.

The Template Method pattern encourages separating high-level workflow from low-level implementations of the steps of the workflow. I often design this as a Workflow module/class that uses a Steps protocol/interface, then implementing the Steps in a separate module/class.

The plugin architecture tends to follow this pattern. The Workflow is a way of managing the lifecycle of the plugin. The lifecycle is a special kind of Steps protocol. Each plugin implementation module implements the Steps protocol/interface.

The lifecycle management workflow doesn't depend directly on any plugin implementation, but only on the steps: create, destroy, pause, resume, save, load, serialize, deserialize, and so on. These "steps" always converge to some highly-abstract concept which stabilizes quickly.

Now I notice at least two key properties of this design:

1. It is stable (because it is very abstract) and

2. It is easy to write contract tests for it.

The Steps protocol stabilizes quite quickly, so it becomes quite safe to publish the protocol/API. Once it stabilizes, the Open/Closed Principle helps us avoid the pain and suffering of changing existing published parts of the API.

The Steps protocol is very abstract, so it makes only a small number of demands on the implementers. We can quite easily express those rules as contract tests. If we publish those contract tests with the Steps API, then implementers know how to implement the API correctly.

So in summary, #tdd and evolutionary design tends to guide my designs in the direction of the Template Method, which allows the Workflow and the Steps to evolve independently. (Less pain.) The Steps protocol tends to stabilize quickly. (Open/Closed Principle. Less pain.)

The plugin architecture is just one way to use Template Method.

With that, I have finally finished this thread... unless there are follow-up questions. :)