It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.

Poltergeist classes add complexity, extra code to maintain and test, and make the code less readable—the reader first needs to realize what the poltergeist does, which is often almost nothing, and then train herself to mentally replace uses of the poltergeist with the class that actually handles the responsibility.

Examples and signs

A couple of years ago, while working on my master's degree, I was a teaching assistant for a first-year Java programming course. For one of the labs, I was given the lab material which was to be on the topic of stacks and using linked lists to implement them. I was also given the reference "solution". This is the solution Java file I was given, almost verbatim (I removed the comments to save some space):

import java.util.EmptyStackException ; import java.util.LinkedList ; public class LabStack < T > { private LinkedList < T > list ; public LabStack () { list = new LinkedList < T >(); } public boolean empty () { return list . isEmpty (); } public T peek () throws EmptyStackException { if ( list . isEmpty ()) { throw new EmptyStackException (); } return list . peek (); } public T pop () throws EmptyStackException { if ( list . isEmpty ()) { throw new EmptyStackException (); } return list . pop (); } public void push ( T element ) { list . push ( element ); } public int size () { return list . size (); } public void makeEmpty () { list . clear (); } public String toString () { return list . toString (); } }

You can only imagine my confusion looking at the reference solution, trying to figure what the point of the LabStack class was, and what the students were supposed to learn from the utterly pointless exercise of writing it. In case it's not painfully obvious what's wrong with the class, it's that it does absolutely nothing! It simply passes calls through to the LinkedList object it instantiates. The class changes the names of a couple of methods (e.g. makeEmpty instead of the commonly used clear ), which will only lead to user confusion. The error checking logic is completely unnecessary since the methods in LinkedList already do the same (but throw a different exception, NoSuchElementException , yet another possible source of confusion). To this day, I can't imagine what was going through the authors' minds when they came up with this lab material. Anytime you see classes that do anything similar to the above, reconsider whether they are really needed or not.