Empty Derived Classes Vs Type Property

Question

I am having trouble identifying the pros and con of these two example below. Ideally I would like to know which weighs high as best design:

Example 1 (Type Property):

public abstract class Animal : /* all relevant interfaces*/
{
    /*
    All necessary implementations
    */
}

Public class Dog : Animal
{
    Public string Name {get; set;}
    Public Breed Type {get; set;}

    /* 
    All necessary implementations
    */
}

Public Type Breed
{
    Bulldog,
    Chihuahua,
    Labrador,
    /*
    So on……
    This can grow without limitation, 
    you dno't know how much it will grow into, or 
    what breed you will have tomorrow e.g BulldogChihuahuaCross, 
    or BulldogLabradorCross.
    */
}

Example 2 (Empty Derived Classes):

public abstract class Animal : /* all relevant interfaces*/
{
    /*
    All necessary implementations
    */
}

Public class Dog : Animal
{
    Public string Name {get; set;}

    /* 
    All necessary implementations
    */
}

Public class Bulldog : Dog
{
   /* Empty Class */
}

Public class Chihuahua: Dog
{
   /* Empty Class */
}

Public class Labrador: Dog
{
   /* Empty Class */
}

Edit:

In the example 1, an instance of Dog is created and it's type is assigned as property, in example 2, an instance of that specific type is created.

I am looking for some indepth argument, scalability, maintainablity, cost on on CPU if there are 1000 types of breed, cost on running queries, ect.

Answer 1

There are two extremes on a spectrum. On one end are sets of things that are merely informational and manipulated as text, numbers, or references to enumerated instances. For example, a dog salon application might record your pet’s name, color, and breed, merely as text for identification purposes. On the other end of the spectrum are sets of things that need to have different properties, operations, or methods. For example, a video game might want to emit a different sound for each breed of dog when it barks.

The decision one has to make as a designer is how accurately to reflect the “domain of discourse” vs. when to take shortcuts for a particular application. In the domain of discourse, each breed has characteristics that make it unique, but for the purposes of a dog salon application, you just don’t care. In that case, you could design away the detail and hope you never need it in the future.

The problem lies in the middle of that spectrum, where someone makes the wrong decision. I have worked on large enterprise systems, where someone squashed an inheritance hierarchy into types explicitly encoded as values in one or more database columns. This was horrific because it became the programmers’ problem to know which other columns were valid for every encoded type. The system had switch statements all over the place to implement business rules that evolved over time into something very complex. The system had lots of bugs.

For that reason, in the middle of the spectrum, where things are not so clear cut, I would err on the side of many classes. The reasoning is that accurately reflecting the domain makes it easier to tell whether or not requirements are met, and can make the code more intuitive to maintain (assuming it’s DDD). The key to reflecting the domain is accurately representing sets of things. For example, “Fido” is a member of the Dog set and of the Animal superset; “Sylvester” is a member of the Cat set and of the Animal superset. This is easy for people to understand, and each class can have different implementations hidden from the outside. Once you start interpreting types explicitly encoded as strings, integers, or enumeration-literal references, you start needing switch statements all over the place, and you have an unmaintainable, hard to understand mess. Many OO languages can save you from all that, but you have to create a factory with a complete list of types. The runtime overhead is negligible (especially if you implement the factory to run in constant time), and the types can be mapped to values in a relational database so you can query and report on them. Besides, as you point out, you may be able to take advantage of generics.

If you know your classes will always be empty, as is the case in a dog salon application, don’t bother with classes. If you know they will have different properties, operations, and methods, or if you’re not sure, use classes.

Answer 2

The first way would let you determine which breed the dogs are, but the second way would let you make specific implementations for the subclass.

Go with derived classes if you are going to need the objects to have different methods or properties for each different dog breed, otherwise it's simpler to just have the type property and a single class.

Answer 3

Ok, so here are my 2 cents: If you are looking for a fast access to anything, you'd put it in a associative array. Both of your implementations deliver a hash code to be used (being the object address) wich makes them accessible at the same speed. Sub-classing makes sense (basically) only if you intend to add functionality. Getting the type from a classifier is no different to getting it from the enumeration. If you need clever queries, create a clever associative array.