OOP, class/objects overkill.

Question

What is a good gauge for knowing when a class is poorly designed or even necessary. In other words when to write a class and when no to.

Answer 1

A lot of people will say the "SOLID Principles" are a good guideline for class design.

There are a lot of articles/podcasts concerning the SOLID Principles, just do a quick search. Here's a good start:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

SOLID might help if a class is poorly designed, but it won't help answer a question like "Is object-oriented programming the best approach for this problem?"

People have done a lot of very good work in programming for mathematics and science before object-oriented programming came into vogue. If your problem falls into those categories, perhaps object-oriented programming isn't for you.

Objects are state and behavior together; they tend to map onto problem domain objects one-to-one. If that's not true for your problem, perhaps object-oriented programming isn't for you.

If you don't know an object-oriented language well, perhaps object-oriented programming isn't for you.

If your organization doesn't know and can't support object-oriented solutions, perhaps object-oriented programming isn't for you.

Answer 3

On top of the SOLID principles, have a look at Code Smells. They were mentioned first (IIRC) in Martin Fowler's "Refactoring" book, which is an excellent read.

Code smells generally apply to OO and also procedural development to some degree, including things like "Shotgun Surgery" where edits are required all over the codebase to change one small thing, or "Switch Case Smell" where giant switch cases control the flow of your app.

The best thing about Refactoring (book) is that it recommends ways to fix code smells and takes a pragmatic view about them - they are just like real smells - you can live with some of them, but not with others.

Answer 4

rather than list a bunch of don't-do-this rules for recognizing a poorly-designed class, it is easier - and more efficient - to list the few rules governing a good class design:

• a class is a collection of related state and behavior
• the behavior should use only the state and method parameters
• if you think about the state as a relation (i.e. as the columns in a relational database table), the object ID (pointer) is the primary (synthetic) key and the state comprises the non-key attributes. Is the object in third normal form? If not, split it into two or more objects.
• is the lifecycle of the object complete? In other words, do you have enough methods to take the object from creation through use and finally to destruction/disposal? If not, what methods (or states/transitions) are missing?
• is all of the state used by at least one method? If not, does it provide descriptive information useful to a user of the object? If the answer to both of these is no, then get rid of the extraneous state.

if the problem you're trying to solve requires no state, you don't need an object.

Answer 5

One of the best gauges I've ever found for poor design in general is peer review.