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!