2

After a short discussion in the comments here I have come to wonder whether or not a baseclass like Animal in the traditional OOP example should be marked as abstract or not.

Personally I believe it should: there is no such thing as an "animal", it is merely a term that groups certain subtypes based on what they are. Any instance of an "animal" should be a subtype, a concrete example.

The comment that followed on this was

There most certainly is such a thing as an Animal. Or would you insist that Dog be broken down into Affenpinscher, IrishWolfhound, SiberianHusky, EnglishSetter, and 600 other breeds?

which is a fair remark but that is different from the original situation where the hierarchy was

enter image description here

And there are no subclasses of Dog in the first place. Should there have been then yes, Dog should be abstract because the tree includes more specific leafs for that specific type.

I can only assume that the reason you wouldn't make it a specific subtype is when you simply don't know it. I would instead add a "default" implementation of a dog to account for this so I can keep the Dog class itself abstract so there wouldn't be any ambiguity possible: you are forced to either create a specific dog or indicate that you don't know the type.

Furthermore it also allows you to create abstract methods that every dog should implement for themselves because they are dogtype-specific. By using a non-abstract class you can't do this and you'll have to remember to override each method in the subclasses.

enter image description here

In the above tree I would make Dog, Mammal and Animal abstract and allow the others to be instantiated.

The question boils down to this: should you be able to instantiate a class that exists to indicate a subspecies or should you defer the creation of such a "general" object to a subtype?

closed as primarily opinion-based by GlenH7, Dan Pichelman, Bart van Ingen Schenau, Tulains Córdova, gnat Aug 4 '14 at 3:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Consider that BufferedInputStream is a subclass of FilterInputStream, which is not abstract. I'm sure there are dozens of such examples in the Java API. – Daniel R Hicks Aug 3 '14 at 14:14
  • 1
    I believe hiearchies like that don't make any sense from OOP perspective. Primarily because they don't express hieararchy of behaviors. – Euphoric Aug 3 '14 at 17:37
  • 1
    Opinions are heavily divided on the question whether non-leaf classes should be abstract or not. – Bart van Ingen Schenau Aug 3 '14 at 17:58
  • 2
    When you're working with animals you can't really instantiate a class dog, because what would it be? A dog has a race: Doberman for instance. In the real world, where you're programming, you can easily instantiate your TStringList class, work with and but also derive a TStringListWithPictures from it and work with that. To me the animal references just make it harder to think about OO. – Pieter B Aug 3 '14 at 21:27
  • 2
    The whole "Hierarchy of Animals" example is such a poorly conceived exercise for an Object Oriented design. There's no way to answer how it should be modeled without knowing just what about the animals is important. In most real programs, it's probably more than enough to just model an "Animal" with its various traits, such as its taxonomy, as class members. If every animal species gets its own class, you'll be stuck deriving a class hierarchy until you go insane. – KChaloux Aug 4 '14 at 13:09
4

Think about the scope of your business logic. If your application records sounds made by your pets, you may want to make a difference between dogs and cats; otherwise, when you call myCat.Bark, something may go wrong. On the other hand, an Irish wolfhound barks, and a Siberian husky barks as well, making this distinction irrelevant.

In this case, Dog and Cat would be actual classes, and Animal will be abstract.

On the other hand, if your application handles different breeds of dogs and cats, the difference between a Siberian husky and an English setter becomes relevant.

Now, Affenpinscher and IrishWolfhound will be actual classes, while Animal or Dog would be abstract.

The comment:

There most certainly is such a thing as an Animal. Or would you insist that Dog be broken down into Affenpinscher, IrishWolfhound, SiberianHusky, EnglishSetter, and 600 other breeds?

doesn't take scope in account. When all I want is to record the sounds of cats and dogs, business-wise, there is no such a thing as an instance of the Animal class: it's either a dog or a cat. If it's a dog, his breed doesn't matter; it may be a property of Dog class, but certainly not a part of the class hierarchy.

  • Huskies don't really bark, but they definitely "talk" a lot. – Derek W Aug 4 '14 at 1:42
2

Unless each subtype adds distinct behavior, the differences will present themselves as attributes of the various instances, e.g., breed, color, weight, etc. I doubt very much you'll need to model a TwentyEightPoundBlackIrishWolfhound as a subclass.

If you're building a Twenty Questions game (Is it an animal, vegetable, or mineral?) a concrete Animal class might make sense.

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