Characteristics Of Good Object Oriented Programming

In the long discourse of ObjectRelationalImpedanceMismatch, CostinCozianu asked the question, What are the characterstics of good object oriented programming? Interesting question and I was surprised that I couldn't quickly find a page on the WikiWikiWeb that described the core qualities of good ObjectOrientedProgramming.

I think it would be good to distill to as few as possible, orthogonal characteristics.

Here's a stab:

OnceAndOnlyOnce (both DataNormalization? and CodeNormalization)

CouplingAndCohesion (LowCouplingHighCohesion?)

Neither of these characteristics is inherently limited to being expressed in OOP. I don't think you can say that these are 'specifically characteristics of good OOP any more than they should be good characteristics of FunctionalProgramming for example. -- IainLowe

The Goal of OO programming is the same as any other programming: To create "high quality" programs as quickly as possible. The exact definition of "quality" depends on what the customer wants but commonly includes speed, no bugs, maintainability (indirectly), ease of use, and the other usual suspects. "Good" OO programming is programming that meets this goal better then "bad" programs would have. Good OO programming this almost inevitably has OnceAndOnlyOnce, LowCouplingHighCohesion?, and the other usual qualities, but in the end, the only final judge of the "goodness" of the OO program is whether it meets the user's needs (including out into the future). Thus, if you want a practical measure of the "goodness" of OO, there is a fundamental circularity in the definition of "goodness". Good OO programs are high quality, and high quality programs are good. (Note the OO drops out!)

You can talk about our experiences about what is good, but all such discussions must inevitably bow to whether or not the program meets the needs of the customer.

That said, practically speaking, I'd venture to agree that OnceAndOnlyOnce and LowCouplingHighCohesion? are very good high-level metrics that pretty much cover everything (and there's even a high degree of redundency between those two). The observation that those are not limited to OO is merely an indication that OO isn't the be-all, end-all of programming, but doesn't change the fact that if you have an OO program, those are still very good metrics for measuring how good they are.

Note that this doesn't necessarily help a lot in deciding in advance how to approach a program; even as I write this, I have this piece of code that is almost perfectly OnceAndOnlyOnce, and LowCouplingHighCohesion?, and is virtually impossible to use because it's too difficult. I'm going to refactor it, in the end having the same basic pieces, but it'll be a lot more useful in the end. Theoretically, the design has nothing wrong with it as is. The badness lies in the fact that it doesn't meet the customer's (in this case fellow developers) needs. As is almost always the case, metrics for measuring goodness after the fact don't necessarily lay out a path to meeting them. (The fact that I would score a 1.0 or worse in an Olympic gymastics competition does not tell me how to get to a 10.0, only that I am not there yet.) -- JeremyBowers

I don't believe that polymorphism is a characteristic of good object oriented program, rather it is a fundamental tool for achieving both OnceAndOnlyOnce and LowCouplingHighCohesion?.

Objects are active. Good OO concentrates on getting the message to the object in a position to do something about it (that knows about the data necessary to carry out the instruction). This leads to the properties given above. Polymorphism is a mechanism for achieving active objects.

In the spirit of WhatNotHow

… the 4 major principles that make a language object-oriented: EDPI
- Encapsulation
  - is the hiding of data implementation by restricting access to accessors and mutators
- DataAbstraction?
  - is the development of classes, objects, types in terms of their interfaces and functionality, instead of their implementation details
- Polymorphism
  - means one name, many forms
  - manifests itself by having multiple methods all with the same name but slightly different functionality
- Inheritance
  - Objects have with each other either a “has a”, “uses a” or an “is a” relationship, each demonstrating a a different way of relating objects
Pasted or modified from
- http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming

Note that some of us believe that these "principles" don't necessarily lead to better code just by their mere existence. The above are tools or options to be used when appropriate but not necessarily everywhere. Used in the wrong place or too much they can create messes such as e-bureaucracies, combinatorial interface explosions, dependency headaches, and verbosity. See ArgumentsAgainstOop for specifics.

See:

http://www.devirtuoso.com/2009/06/10-characteristics-of-good-program-design/