On Object Oriented Design

I thought I knew object oriented programming (OOP)... I was so wrong!
Well, at least now I know that this is not something everybody gets. It takes a number of "aha" moments, full of blazing insight, before you can think in terms of objects.

Back in college, OOP, at least to me, was always about creating a small programs where the ideas of

  • Objects/classes
  • Information hiding (encapsulation),
  • Inheritance,
  • Interfaces and
  • Polymorphism could be demonstrated.
Design patterns were absolutely unheard of.
However, the true power of OOP is only realized when you apply it in a project of some size, with many people working in tandem on the same entities.
So, how do you know if your code is perfectly object oriented or just pretending to be? I've observed the following indicators of good OO code:
  • Easily maintainable/modifiable: If you had to make an extension to the existing features, how long would you take? If you can't instinctively name all the classes where some more code is required in this situation, it probably isn't OO.
  • Extensive use of Design Patterns: It is difficult to get the object communication strategies right without the right theoretical and practical background. So, you will see design patterns applied in good OO code. Fluency in this area, they say, comes with experience.
  • Too many special cases: If the code has comments explaining why a special hack had to be included to take care of a use case that was later added to the requirements, it means that the class design is faulty, and the designers should have put more thought into their work.
  • Lengthy class methods: This is one indicator that your methods are doing too much, and therefore not exactly what they are expected to.
  • Many statics floating around
  • Using UML: If you find yourself referring to the UML diagram too frequently, when the diagrams are not overly complex, chances are that the code is not very well designed. Coding tends to happen much more naturally when the designed classes reflect the domain accurately.
  • Programming to an interface
When designing a new application, I used to start off with the database, which is actually an implementation detail. Now I'm beginning to realize that step 1 is always object oriented design, and it is important because decisions taken at this stage will come back to haunt you later if you do not pay enough attention.