Classic Oo Anti Patterns

A list of common AntiPatterns:

See also CodeSmells

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.



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?

View edit of September 5, 2011 or FindPage with title or text search