There was a recent blog posting making the rounds on Twitter earlier this week about the old “Is a Square a Rectangle?” problem. It’s a nice post and a quick read. Here’s the URL: http://21ccw.blogspot.com/2009/01/is-square-rectangle.html. The Square/Rectangle discussion was going on way back in the early 1990’s on Usenet and it’s still applicable today. When I’m teaching, I’ll transition to the topic of the Liskov Substitution Principle by asking the class the question, “Is a square a rectangle or is a rectangle a square?” (sometimes I’ll substitute circle and ellipse for square and rectangle, just for my own amusement). I’ll ask for a showing of hands, “How many people think that a square IS-A rectangle?” I’ll draw the UML for Square inheriting from Rectangle on the whiteboard as I start this topic. The reason I say this problem is still applicable today is that 99% of my students will raise their hands. The remaining 1% either don’t know, don’t care, or they are enlightened and know that it’s a trick question. After 15 years, I find it hard to believe that everybody programming in (strongly typed) OO languages doesn’t know how to look at this problem. On the other hand, I guess I should be happy as the ignorance that exists in our industry provides a steady stream of business for us.

My classes usually chuckle when I explain how I tricked them by using that cutesy little phrase “IS-A” as I draw the UML for inheritance on the whiteboard. I explain that there isn’t enough information in the question to give an answer. Before we can say whether or not a Square should inherit from a Rectangle, we must first specify the behavior of a Rectangle. We must know what a Rectangle object can do and we must know the expectations of the clients of Rectangle. I ask the class, “Can a Rectangle have its width set independently of its height?” Everybody agrees that setWidth() and setHeight() should be methods of Rectangle. The Liskov Substitution Principle says that if a Square is to inherit from Rectangle, a square object must also respond to setWidth() and setHeight() requests. Square can certainly override those methods so that when a client calls setWidth(), the setWidth() method sets both the width and the height, maintaining its squareness. Ditto for setHeight(). The crux of the matter comes down to the expectations of the clients of the base class Rectangle. If they are interacting with a Square object through the Rectangle interface, wouldn’t they be surprised if they called setWidth() and both dimensions of the target object changed? Sometimes the answer could be yes, sometimes it could be no – it depends upon the context.

We’ve come a long way from “IS-A”. Clearly the reasoning of an inheritance architecture is more involved than questioning if something “IS-A” something else, in some sense of the word. If we must use a cutesy phrase, a better one, and one that adheres to the Liskov Substitution Principle would be “Is Substitutable For”.

Before I joined Object Mentor, I used to work with a guy who actually taught “IS-A”. He was well respected in the organization (not by me, I thought of him as the village idiot) and would tell people to go through the requirements document looking for the phrase “is-a” between two nouns. The nouns are classes and the “IS-A” association signals the use of inheritance. How can anyone with the slightest modicum of intelligence believe that this could work? He was actually telling people to base the architecture of their systems upon the linguistic skills of whoever wrote the requirements document. I’m glad I don’t work there anymore.

Don’t even get me started on “HAS-A”.