If you're good at what you do, you can judge when to employ which design patterns. And, on the other hand, when employing said design patterns would make the means too complicated to justify the ends. Dale M. sent in an example of this sort of overcomplication:

Interface: 10 lines (4 Lines Of Code w/o comments)
     core/src/com/.../enterprise/util/codetable/IYesNo.java
Factory: 141 lines (69 LOC)
     core/src/com/.../enterprise/util/codetable/YesNoFactory.java
     (Note that the factory includes an inner class called YesNoInstanceType)
Abstract class: 43 lines (17 LOC)
     core-restricted/src/com/.../enterprise/util/codetable/restricted/YesNo.java
Concrete class: 87 lines (61 LOC)
     core-restricted/src/com/.../enterprise/util/codetable/restricted/nonpersistent/YesNo.java

This is a total of 151 lines of code. For a class that has a value of either yes or no. I'll have to double check my java documentation, but I'm fairly certain that java has a built-in datatype for storing boolean values. Now if only I could remember what the boolean type is called in java... oh yeah. "Boolean." Seeing the word "enterprise" in the file paths speaks volumes.

That wasn't all Dale gave us, though. Here's a usage example:

YesNoFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase());

I can't imagine a single scenario in which creating an instance of the YesNo class using the YesNoFactory's "getFactoryInstance" method is simpler than using a boolean or an enum, and this is exactly the kind of thing that will trip up new developers that have to maintain ridiculously (and unnecessarily) complex code.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!