Object-Oriented Design Heuristics


Object-Oriented Design Heuristics is the book I’ve been reading for the last two months. Besides of the amount of work in this period, I could always find some time to read it.  The book has 11 chapters and, without appendixes, 217 pages. So, it’s not a exhaustive reading.

The most interesting in this book is the fact that it address an issue that every programmer think he/she knows: object-oriented programming. I was one of them. I thougth that I knewn object-oriented programming and now I realized that this paradigm envolves more than I ever suspect.

The book offers insight into object-oriented improvement. The more than sixty guidelines presented are language-independent and allow you to rate the integrity of a software design. The heuristics are not written as hard and fast rules and cover important topics ranging classes and objects to physical object-oriented design.

As you might be curious about the heuristics, I will be nice and tell some of them:

  • Be sure the abstractions that you model are classes and not simply the roles object play: is Mother and Father a class, or the role that certain Person objects play? The answer depends on the domain that a designer is modeling. If, in the given domain, Mother and Father have different behavior, then they should probably be modeled as classes. If they have the same behavior, then they are different roles that object object of Person class play.
  • Do not create god classes/objects in you system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem: developers attempt to capture the central control mechanism prevalent in the action-oriented paradigm within their object-oriented design. The result is the creation of a god object that performs most of the work, leaving minor details to a collection of trivial classes.
  • A class must know what it contais, but it should not know who contains it: this heuristcs is important if a designer wishes to reuse his or her abstractions. Consider the relationship “BedRoom contais AlarmClock”. It is necessary that the BedRoom object knows about its contained AlarmClock object, but the AlarmClock should have no dependencies on the BedRoom. The main reason is reusability. I want to use the AlarmClock out of the BedRoom in the future. If the AlarmClock is dependent on the BedRoom, then the BedRoom goes wherever the AlarmClock goes.
  • If you have an example of multiple inheritance in your design, assume you have made a mistake and then prove otherwise: this heuristics is meant to emphasize the large level  of multiple inheritance misuse that existis in many object-oriented designs. So, assume that there is a mistake first.

Well, it’s good for now. If you like the advices, there are a lot more inside the book.

See you,


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s