What are the tell-tale signs of bad object oriented design? [closed]

Question

When designing a new system or getting your head around someone else's code, what are some tell tale signs that something has gone wrong in the design phase? Are there clues to look for on class diagrams and inheritance hierarchies or even in the code itself that just scream for a design overhaul, particularly early in a project?

Answer 1

The things that mostly stick out for me are "code smells".

Mostly I'm sensitive to things that go against "good practice".

Things like:

• Methods that do things other than what you'd think from the name (eg: FileExists() that silently deletes zero byte files)

• A few extremely long methods (sign of an object wrapper around a procedure)

• Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)

• Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)

• A class that has lots of responsibilities (violation of Single Repsonsibility principle)

• Long chains of member access (this.that is fine, this.that.theOther is fine, but my.very.long.chain.of.member.accesses.for.a.result is brittle)

• Poor naming of classes

• Use of too many design patterns in a small space

• Working too hard (rewriting functions already present in the framework, or elsewhere in the same project)

• Poor spelling (anywhere) and grammar (in comments), or comments that are simply misleading