Sometimes a project is made more complex than it needs to be, hundreds of abstract classes. Sometimes it can be because the developer is so far up in the clouds of technical minutae that they have forgotten how to write code that is easy for others to use, or as proof that they are a programming genius - the software equivalent of a cat marking its territory.
For example, some developers start at the abstraction end and work their way through to the concrete end. This can be fine for larger, complex projects, but for small bodies of work this is over-engineering. For example, abstracting thirty interfaces to write a small single-page throw-away web application is over-engineering because the same can be accomplished in a few files.
Some types of data needed to be rendered in appropriate formats for the user to see. The first developer decided they would create a Renderer interface, a RendererFactory interface, an HtmlRenderer interface, some concrete implementations, some singletons etc.
public class HtmlUtil
{
public String getDateHtml(Date date)
{
HtmlRenderer renderer = RendererFactory.getFactory(RendererFactory.DATE);
return makeSafe(renderer.render(date));
}
public String getStringHtml(String s)
{
HtmlRenderer renderer = RendererFactory.getFactory(RendererFactory.STRING);
return makeSafe(renderer.render(s));
}
public Integer getIntegerHtml(int i)
{
HtmlRenderer renderer = RendererFactory.getFactory(RendererFactory.INTEGER);
return makeSafe(renderer.render(i));
}
:
}
The second developer simply created some brute-force methods that did what was required, no more. They kept an eye on how complex the result was getting with the option of “scaling-up” the complexity and flexibility. But as it turned out, with only three data types for the screen, this did not need to occur.
public class HtmlUtil
{
public static String getDateHtml(Date date)
{
return makeSafe(DateUtil.renderAsHumanReadable(date));
}
public static String getStringHtml(String s)
{
return makeSafe(s);
}
:
}
The specific code will likely never be touched again so which developer did the right thing? The second one because software ownership has a cost and a simpler application is cheaper to maintain.
Tip: Once a body of work is completed, review if the complexity was warranted.
Scale up if required along the way.
It's easy to change a class into an interface later.
