So. Squares violate the assumptions that Rectangles established. Where did these "assumptions" come from? Surely the programmers are not looking at the implemen

So. Squares violate the assumptions that Rectangles established. Where did these "assumptions" come from? Surely the programmers are not looking at the implementation of a class rather than its interface? If we have a language and a system where you have an elaborate vocabulary for constraining the types of messages we can send to an object and the parameters we can associate with those methods but we have absolutely zero ways to constrain what those messages will return and what changes of state those messages will cause... Well then there are going to be these kinds of arguments. I think tools can help here. For one thing, we could use languages like Eiffel that give us Design by Contract that is checked by the compiler. If setting the width is not supposed to set the height, we can make that part of the contract for the setWidth(...) method of a Rectangle and our compiler will not allow us to write a Square class that is-a Rectangle. And alternate approach with less strict languages is to write tests for Rectangle. I'm a big fan of Strict Liskov Equivalence (http://weblog.raganwald.com/2008/04/is-strictly-equivalent-to.html http://weblog.raganwald.com/2008/04/is-strictly-equivalent-t...). In a project with tests, I believe that any test written for the Rectangle class should work for instances of all of its subclasses. Therefore if we write a test for the rectangle class and we include a check that setting width does not affect height, then a Sqauare cannot be a Rectangle whether the compiler barks at us or not. The test in our project establishes that expectation for all Rectangle subclasses. OTOH, if no such test exists, than the programmer making that assumption is wrong. She should either drop the assumption or add the appropriate tests to the project to document her understanding of the contract of a Rectangle.