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
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.
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?
7
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.
1
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.