The idea here is to prefer simple solutions, hoping that the simple solution will pay off in the long term by reducing current and future design and maintenance cost.
Managing Simplicity posits that this will be true enough of the time to make it a default choice. Of course you have to look at opportunity cost, and weights of risks, rewards, and efforts.
Here are the areas where Managing Simplicity spells out steps that are proven to save effort in the long run.
The Refactoring Rule of Three.
The first time, just write the code to get it to work.
The second usage, copy the code, make it work for the new instance.
The third usage, look for commonality, and do a simple refactoring.
So any time you have four blocks of code that smell of Cut-and-Paste, look to refactor the code in the simplest way to eliminate redundancy.
When you get to three redundancies at the next level, then consider fancier refactorings. That is, the following code is redundant, but OK, because it is only done twice:
ContainerNode copyright = new ContainerNode("Copyright"); copyright.setDesigner(new CopyrightDesigner()); TreeItem copyrightItem = ContainerNode.createTreeItem(copyright); getContainingTreeItem().addItem(copyrightItem); ContainerNode websites = new WebsitesContainerNode("Websites"); websites.setDesigner(new ListDesigner(websites)); TreeItem websitesItem = ContainerNode.createTreeItem(websites); getContainingTreeItem().addItem(websitesItem);
When you get three of these babies, do a simple refactoring, which is to move the code into a factory method, passing in the things that are different.
However, when you get to three different variations of how you call your factory method, look to fancier things, like Interfaces, Introspection, Spring, and so on.