We have just used the concepts from the start of the chapter to implement a pattern that is designed to be extended. We could have written the previous three recipes in one step and in one class, which is often the case. By separating the code into distinct classes, we have created a reusable purchase order generation class, a facade to ease its usage, and a framework to allow a functional consultant to determine how it is used. Should the customer change their mind on which conditions the code should run, it is done without changing code.
This should reinforce why interfaces are useful. We were able to write the whole framework without implementing the specific create purchase order action.
There will be cases where a code change is made, but this would be to enable a scenario and not write that scenario into code.