A square is not a rectangle?
rectangle => closed shape with straight edges and four right angles
square => rectangle with equal sides
What am I missing?
Iâm not sure what youâre replying to but this is a well known argument when discussing behavioral subtyping (a.k.a. the Liskov substitution principle). The problem is known as the âSquareâRectangle Problemâ or âCircleâellipse problemâ.
A short executive summary of the Liskov substitution principle (LSP) is: âAn object of a subtype can be used like an object of the supertype, without the code knowing that this is a subtype or how it behaves differently.â
In a language where a type Rectangle is mutable you can set the width and height independently of each other. If a type Square inherits from Rectangle things get complicated: What does it mean if the width or height gets modified? Should the other dimension also change or should the operation result in an error? Is either of those alternatives acceptable or do they violate the âdesirable propertiesâ of the Rectangle supertype?
My observation is that there are three groups of people in this discussion. The first argues that squares are rectangles so the inheritance hierarchy should reflect that. The second argues that from the viewpoint of the interface or the postconditions objects of the two types behave differently so they should be independent types. The third groups tries to resolve the contradiction by differentiating between the specification and the implementation, or introducing new concepts like âemerging propertiesâ.
You can find lots of discussions about this on the web, e.g. on StackOverflow or on softwareengineering.stackexchange.com.
2 Likes
Thanks for replying. I was making an observation as an ex Maths teacher, where in introducing Set logic examples such as âsquares are a subset of rectanglesâ are common.
If squares arenât subsets of rectangles in behavioural subtyping land then definitions need to be amended surely? Donât the rules of elementary Maths apply?
I agree it boils down to definitions.
âSubsetâ in the math realm doesnât necessarily mean âsubtypeâ in object inheritance.
I think thatâs my point. If one is going to use Math examples, then one needs to follow the Math rules, not invent new ones. Call them something else by all means.
Your issue is not with the subtype concept, but with the use of the terms square and rectangle. What have been called such above are in fact not at all the familiar geometric objects.
I think thatâs the point of that title 
You read the title, think, âBut a square is a rectangleâ then read how having a Square object inherit from a Rectangle object doesnât necessarily work very well. The title isnât actually what is being argued; the title is meant to catch your attention and make you think about inheritance.
While this discussion comes up I have a question to those OOP gurus. I didnât do a lot of OOP in the past years. My main language is Go for many years. But Iâm wondering if some should really care about that problem, using a object âsquareâ (it just should fullfil all math constraints to me and work great with inheritance).
Isnât it that this is exactly what the object should do: Encapsulate its logic? Letâs say most animals walk forward. And now there are those who do walk sideward. I donât care as long as I can say: You animal, please walk. Wrong? I mean, interfaces - like I use and know them - say what I can do with something. But not what will happen with a specific instance. Isnât that true for inheritance or composition, too?
This does an awful lot of work. (And I do not know what, exactly.)
The latter is part of the interface.
Example of interfaces that offer no guarantees about âwhat will happenâ at all are very few, and all are completely useless.
I canât agree with that. I worked on plugin systems or data aggregration stuff and others. Thatâs exactly the point, that you do not know whatâs going on. Thatâs why you have the contract of input and output. Letâs say image filters. You will have no idea what this filter is doing with your image. But you can be sure, youâll get an image back. Like the walking animals. They will give you coordinates where they are, but you have no idea how they did it.
Maybe thatâs really a problem of OOP with too much state in the objects. Or too much publy properties. I donât know.
Such is promised by the interface: you will get something back, and moreover it is an image.
An interface that would make truly no guarantees would have all methods be void, or have return type â a. a (i.e. a value that you do not know anything about), or something.
Needless to say, such an interface would also make no promisses about interactions between these methods. (Not that it matters â any effects of those methods would be unobservable anyway.)
Reading my quoted block again, Iâm sure I got it totally wrong on my way of translation. 
But I still think the âwhat will happenâ has not to be defined. But what will be the expected output.
Hi everyone, just created a new thread to keep the original thread What are your favorite books on programming? - #11 by DeepspaceFreelancer on topic.
Go to town on maths in this thread ;-)
Haha @deleted-user-33691 I really enjoyed the threadâŚI never knew rectangles and squares could generate so much!