Is there a way to use the existing features of object oriented programming languages to work around the square/rectangle problem?

Can a child be defined in terms of being a more restrictive subset of its parent class rather than being defined in terms of additional features?

Former question:

I'm trying to reconcile the difference between object-oriented inheritance and a real-world taxonomy where each child type has FEWER traits than its parent. Inheritance is subtractive. In OO, inheritance is additive.

Suppose we have a class Person. A Person can either be a Customer, with billing info, or an Employee, assigned a department. Further an Employee can either be a Supervisor with direct reports, or a Worker with assignments.

Classical OO inheritance would have Worker/Supervisor inherit from Employee which inherits from Person, where each child class has more characteristics than its parent class.

In the real world, though, it's the reverse: A Mammal has lots of potential features, a Canine has a subset of those features, and a Beagle has an even smaller subset.

Another way to look at it, A quadrilateral can be any shape with four sides. A parallelogram is a quadrilateral with parallel sides. A rectangle is a parallelogram with 90 degree angles, and a square is a rectangle with equal sides.

If I were to model a real-world taxonomy using OO inheritance, how would it be done?

I could start with a parent Square, with a length, and its child be a Rectangle with a length and a height, etc., but this is unnatural given the domain. Is there a way to do Object-Oriented programming inheritance going the other way?

marked as duplicate by gnat, user22815, Community Oct 31 '16 at 17:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 9
    "A Mammal has a lot of potential features" No. All mammals have a small set of common features. All canines are mammals with some additional common features (e.g. all canines have four legs, but not all mammals have four legs). – 8bittree Oct 31 '16 at 17:07
  • 4
    @8bittree Except of course that that taxonomy isn't perfect; there are exceptions; making the hierarchy imperfect. – Servy Oct 31 '16 at 17:08
  • 3
    @Servy Yes, but the point is that you don't make the root of a taxonomy or OO hierarchy describe every single possible feature that could exist somewhere in the taxonomy, you start with only the common features that everything has. – 8bittree Oct 31 '16 at 17:10
  • 4
    @gnat: I'd suggest that Karl Bielefeldt's answer on "Is inheritance that adds rules bad?" makes that a better target. – Josh Caswell Oct 31 '16 at 17:16
  • 2
    I think the other question I linked is a better dupe target: it digs into the problems of modeling real-world taxonomies using OOP inheritance. – user22815 Oct 31 '16 at 17:31

No no no. You're trying to make the issue about whether the root should have more or fewer traits than the child types. Guess what? No one cares!

If I am a user of mammals, I have a certain set of messages I'd like to be able to send a mammal without ripping a hole in the universe. So if I tell a mammal to fly and it turns out to be a dog it's okay for it to tilt its head and look at me funny.

The null object pattern saves us from the hole in the universe.

The traits a mammal should have are neither the traits of every subtype nor the traits common to every subtype. They are the traits needed by the client. No more. No less.

People faced with this problem often obsess on the Liskov Substitution Principle. This is a good thing to follow but the answer to the problem isn't there. It's here: Interface Segregation Principle

ISP tells you not to expose more than is needed to be used. That means neither the root nor the children have any authority in what should be exposed. The user of mammals is the one and only authority here. Everything else is clutter. Designing a taxonomy without considering how it will be used first is a recipe for disaster.

  • Interface! Of course! It seems much more logical. If a person needs a name, why have a dubious Human object when you can have an obvious Namable interface? In fact, why use inheritance at all... – ridthyself Nov 1 '16 at 17:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.