Archive for category SoftwareDesign

OO Design: The Liskov Substitution Principle

If you're an experienced OO developer you should by now know what this principle is. I was having a chat with somebody last week regarding the applicability of this principle in the OO design, especially using Java (which prompted me for this entry).

For starters here is the principle:

"If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T."

In more simple words, it means:

"In class hierarchies, it should be possible to treat a specialized object as if it were a base class object. That is -- if a client is using a reference of the base class, then it should be able to replace the base class with the derived class instance with out affecting any functionality."

To be honest, I was not too keen earlier about some of the book-ish theories and principles. I was attending a training session by ObjectMentor a few years ago, when there was some good discussion in the class about Ms. Liskov's principle. That discussion evoked some curiosity in me and helped to take a fresh look at some of the popular Object Oriented principles.

The discussion topic started off with a question whether a Square is a Rectangle or not? For all practical purposes, in the mathematical world it is but certainly not in the OO world if it has to adhere to the Liskov's Substitution principle. See here for more details on that Squares and Rectangles example (C++) and for a bit more real example.

On a related note, there is one line of thought in the OO arena that Inheritance is one of the most abused concepts in Java. I remember Bruce Eckel mentioning in one of those forum discussions that the design of Java Collections is a possible candidate to fall in to that category. He says that although a Set and a List are containers that hold objects, the similarity ends there and their behaviors are quite different.

This one makes an extreme case of Is Inheritance Necessary. I guess the bottom line here is the emphasis of Composition over Inheritance.

If you're convinced about the principle and the best practice that it emphasizes for the Object Oriented design, for a change read this one. Author suggests that the principle doesn't hold good for Java!

Liskov Substitution principle, although seems simple and straightforward, it would be interesting to know how many applications truly follow the principle.

Tags: ,

Checked vs. Unchecked Exceptions — Never Ending Debate

Yeah, this is one of the favorite combative topic. Battle lines more often are clearly drawn with staunch supporters for both checked and unchecked exceptions.

Although this TSS post avoided going into the controversial topic the discussion followed was not immune to that!

Found this page in the Sun's tutorial handling the issue very well. Bottom line according to this one ..

"If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception."

If that convinces you, here is the Bruce Eckel's perspective. Towards the end of the page Bruce touches the aspect of exceptions in relation with the size of the projects (and I second that thought from my own experience) ..

"... checked exceptions seem to be helpful for small projects, which is generally the space where we argue the point. However, when projects get large (actually, I've noticed it when they are anything except small), checked exceptions get ungainly and seem to cause problems. I would therefore suggest that the reason checked exceptions seem so compellingly "right" at first is that they have been presented and argued in the realm of small examples."

Tags: ,