Relationship is-a, has-a and uses-a

[2kaud]

with some source code shenanigans, it is certainly possible to derive a square class from a rectangle,

As per Wolle's post, in c++ I wouldn't class polymorphism using a pure virtual base class as 'source code shenanigans'!

[h00k]

immutability does not solve the problem that the constructor for a Square cannot replace the constructor of a Rectangle; it merely solves the problem that we can create a square object by instantiating the Rectangle class and pass it over without ever worrying that it will be abused.

Even with implementing generic abstract classes / getter interfaces though, a square cannot be derived from a rectangle without having some redundant getters.

[wolle]

immutability does not solve the problem that the constructor for a Square cannot replace the constructor of a Rectangle; it merely solves the problem that we can create a square object by instantiating the Rectangle class and pass it over without ever worrying that it will be abused.

You mean that my design (in #28) is in accordance with the LSP when it comes to methods but not to constructors? Well, it's common practice not to count constructors as part of a type specification. Barbara Liskov is very clear about this in her paper where the LSP is defined and provides the following motivation,

"Note that the creators are missing. Omitting creators allows subtypes to provide different creators than their supertypes. In addition, omitting creators makes it easy for a type to have multiple implementations, allows new creators to be added later, and reflects common usage."

So the LSP deals with the behavior of existing objects only. Object creation is considered a separate issue.

Even with implementing generic abstract classes / getter interfaces though, a square cannot be derived from a rectangle without having some redundant getters.

It's because the Square subtype in my design (in #28) is more constrained than the IRectangle supertype. Barbara Liskov deals also with this common situation where a subtype is restricting the variability of the supertype. In the aforementioned paper,

"we believe it is better to use variability in the supertype specification and straightforward reasoning methods"

and

"a specifier of a type family has to anticipate subtypes and capture the variation among them in the specification of the supertype."

So Barbara Liskov advices that subtypes express the full variability of the supertype but the supertype should anticipate that some subtypes may be constrained and therefore include methods to deal with that in the specification of the supertype. That's why I specified the isSquare() method in IRectangle.

[h00k]

I am not saying your code is wrong, but that it does not follow the most reliable structure for creating a Square class out of a Rectangle class.

To create the Square class (if have a class of type Square is absolutely necessary), the proper relationship is a USES-A relationship. The Square class should internally create a private square instance, which is probably created by injecting the Rectangle class, and then internally using the methods of the Rectangle class to create the methods of the Square class. However, these are all details that are encapsulated inside the Square class and the user will not be aware of them (aware that the square instance infact has a rectangle instance and that the Square USES-A Rectangle).

[wolle]

I am not saying your code is wrong, but that it does not follow the most reliable structure for creating a Square class out of a Rectangle class.

To create the Square class (if have a class of type Square is absolutely necessary), the proper relationship is a USES-A relationship. The Square class should internally create a private square instance, which is probably created by injecting the Rectangle class, and then internally using the methods of the Rectangle class to create the methods of the Square class. However, these are all details that are encapsulated inside the Square class and the user will not be aware of them (aware that the square instance infact has a rectangle instance and that the Square USES-A Rectangle).

The purpose of my design (in #28) is not to "create a Square out of a Rectangle". If that was my aim I certainly wouldn't have used inheritance. Instead I would've considered composition (HAS-A, USES-A or whatever fits the bill).

The purpose of my design is to treat Square and Rectangle uniformly using a common abstract supertype IRectangle. In this way code can be written using IRectangle variables and it will work equally well with both Square and Rectangle objects.

You claimed this couldn't work because a square isn't a rectangle so inheritance (IS-A) is out of the question. I showed that it would work if the supertype IRectangle is properly specified which includes immutability. Then the LSP would apply and the design would be kosher.

You then objected by pointing at the non-uniform constructors and the fact that Square is a constrained subtype. I showed with quotes from Liskov's famous scientific paper (which defines the LSP) how this is dealt with. (Note that constrained subtypes are fairly common. The Leaf class in the Composite design pattern is one example).

-----

So what's the purpose of your post really? I didn't use inheritance of implementation in my design. I used inheritance of type so there's no brittle superclass problem. I could've used composition to implement Square if I wanted and I could've used Rectangle for that purpose but decided against because that would've been overkill since Square is so easily implemented.

With your design there's no relation between Square and Rectangle so the LSP doesn't apply. Code that uses both must find some other way to distinguish between them and that means the number one benefit of OO is lost.

I drop it here. Thanks for the discussion.

[2kaud]

Usage of the classes drives somewhat the underlying design. If, say, a container is required to accommodate both (c++17 variant not withstanding), then there needs to be a polymorphic relationship so that the type of the container is a pointer to the base class. The same applies if a function is required to have either class as a parameter (although there are other ways of achieving this).

Practically, class design isn't an 'isolated exercise' but part of the overall application design/implementation. i think the apt phrase is 'horses for courses'.

[h00k]

The purpose of my post is to explain to the uninitiated readers who land on this page how inhertiance can be abused and to warn that the common-sense relationships from the real-world or language might not translate into IS-A relationship in OOP.

I am not interested in continuing this discussion either; my point should be clear enough by now.

[wolle]

my point should be clear enough by now.

Your point is right but your aim is a little bit off if I may say so . Maybe you're not used to strong opposition but you cannot just claim things and expect to be taken at face value. It's called peer review. It's not enough that advice is well-meant, it must also be correct

Anyway, thanks again for this discussion and good luck.