Classic Oo Anti Patterns

A list of common AntiPatterns:

EnterpriseApplicationConstructionSet : Instead of focusing on business requirements, a 4GL environment is re-created to become a "application construction set" to solve the anticipated business problems. Very easy to do certain things, extremely difficult when those pesky requirements interfere with the rigid architecture.
ClassesWithoutOo: Putting lots and lots of methods on one big massive "do it all" class. "My," I said, "that's a pretty good ModularProgramming design you have there, but you've kinda' missed the boat on the object thing." Another way to do ClassesWithoutOo is to have method classes that operate on data classes.
AbuseOfUtilityClasses: Classes that have only static methods and no state.
FearOfAddingClasses: The naive belief that adding classes to a design makes it more complicated. "No," the novice said, "we should use this design instead of that one because it's clearly simpler; it has fewer classes and relationships." (...leading to "one big massive 'do it all' class," above.)
ProducingSingletonGarbage: "You get so sick of trying to handle object references without garbage collection that you end up making many classes into Singletons. ..." (...another way to do ModularProgramming in an OO language.)
NotUsingPolymorphism: This, in spite of a year long rewrite, from scratch, by half a dozen developers "to make the system OO." (This example in VB. Project has classes. Search of project reveals not one "Implements" statement in the entire project. There had been a few, but the technical lead demanded that they be removed, claiming that such complexity was "unmaintainable.")
OverlookingParentBehavior (Failure to look to parents for inherited behavior in library classes): "Why hasn't a java.awt.Button got a method to tell me how big it is?" -- ChanningWalton
BadlyFormedPersistenceLayer (Persistence layer is not separatable/swappable, so UnitTests are problematic.)
OverGeneralizing. Generalize it to death. (See "... generalizing it so much it becomes impossible to write ..." below.)
MisUsingInheritance:, especially in has-a relationships. (See PeterCoad's book JavaDesignBuildingBetterAppsAndApplets? for a definitive answer on when to subclass.)
MisUsingMultipleInheritance: Excessive and uninformed use of MultipleInheritance. [examples to follow]
ObjectOrgy: Lack of encapsulation.

Not Refactoring: Use of refactoring will cure all of the above problems. Not refactoring will almost guarantee all of the above will slip into the code and stay there.

TheTimelessWayOfBuilding talks about half-a-dozen words that approximate but do not capture the QualityWithoutaName. OO normalization is similarly an approximation to real quality in a program: it is certainly good if a program is modularized appropriately, if objects understand their own responsibilities, if code is general and specific... but merely having those characteristics does not make it good, and focusing too tightly on them tends to distort things.

OO is so good people that when people first use it they can forget everything else, and get into trouble.

I can't put a name on this one... Please help. A common misunderstanding I've noticed in people who aren't well acquainted enough with objects (including some who claim to be OO programmers) is the confusion between the type of a variable and the type of an instance.

[Perhaps ParkingLotsStoreMoreThanJustCars??]

You might call this the belief that an instance has only one type, I suppose. Or call it "confusing classes with types". Please, someone, come up with something better! :)

You might call this NotUsingInterfaces? similar to NotUsingPolymorphism above

I've had people tell me, "But this won't compile" when faced with the following :

public interface SomeInterface { /* ... */ }
(... in other code elsewhere ...)
public void someMethod(SomeInterface aParameter)

on the grounds that "you can't make an instance of an interface".

[It won't compile in C++ for exactly this reason. The real AntiPattern here is that some people know only one programming language and think they know them all.]

It won't compile because it's java. Java passes objects by reference, so the call does not require creating an instance of an interface. The "equivalent" signature in C++ would be:

public: virtual void someMethod(SomeInterface& aParameter);

Which would compile, and calls to it on a concrete class would succeed.

I think the same kind of misunderstanding is the cause of code like the following :

Vector list = new Vector();
/* ...several lines of code later... */
list = somebody.getList();

(Because, of course, if you have a Vector variable it stands to reason that you must initialize it with a Vector.)

[Different misunderstanding. Why declare a variable you cannot yet intialize? Of course, if you declare a Vector and have nothing meaningful to intialize it with, then you probably want an empty Vector. Or that code got copy-and-pasted...]

Will the name ConfusingTypeWithInstance? work?

Java is pass-by-value, period. Object references are passed by value. This achieves similar effects to pass-by-reference when mutating the referred object, but the passed reference itself can not be mutated. This argument seems to split hairs, but the subtle distinction is important for anyone who truly wants to understand the calling convention.

CategoryAntiPattern

Discussion:

Something is smelling here. DRY has not to be used just in code. Some of the ideas presented here are very close to those presented in CodeSmell. Am I wrong?