Simplicity: Self-Documenting Code, Adapter Pattern
Simplicity is the eye of the beholder. It doesn’t matter much if you think the design is simple; if the rest of your team or future maintainers of your software find it too complicated, then it is.
To avoid this problem, use idioms and patterns that are common for your language and team, It’s OK to introduce new ideas, too, but run them past other team members first. Be sure to use names that clearly reflect the intent of your variables, methods, classes, and other entities.
Pair programming will help you create simple code. If you have trouble understanding something your partner wrote, discuss the situation and try to find a better way to express the concept. Before you use a comment to explain something, ask your partner how to make the code express its intent without needing a comment.
Adapter Pattern, Isolating third party components
A hidden source of duplication lies in calls to third party components. When you have these calls spread throughout your code, replacing or augmenting that component becomes difficult. If you discover that the component isn’t sufficient for your needs, you could be in trouble.
To prevent this problem, isolate your third party component behind an interface that you control. Ask yourself “When I need to upgrade or change this component, how hard will it be?”. In object oriented languages, consider using the “Adapter Pattern” rather that instantiating third party classes directly. For frameworks that requires that you extend their classes, create your own base classes that extend the framework classes, rather than extending the classes directly.
Instead of supporting every feature of the component in your adapter, support only what you need today. Write the adapter’s interface to match your needs, not the interface of the component. This will make it easier to use and to replace when necessary.
Isolating third party components reduces duplication at the cost of making your code slightly more complex.
