Some snarks are boojums: list of boojums, or is_boojum property on all snarks?

Question

The problem domain features a large population of named snarks. Some of the snarks are boojums.

There are at least two ways to model this:

// as a property: 
    class Snark { 
      string name; 
      bool is_boojum; 
    };  

// as a list:
    class Snark { 
      typedef long Id;
      Id id;
      string name;
    };  

    tree<Snark::Id> boojums;

It seems intuitive that if we determined that snarks come in male and female, we would add a "sex" property to the snark class definition; and if we determined that all but five snarks were vanquished subjects, we would make a list of royals.

Are there principles one can apply, or is it a matter of architectural preference?

Answer 1

What problem are you trying to solve?

If the purpose of recording the royalty of the snarks is to display a crown on their heads in the GUI, then it makes sense for it to merely be an attribute. (Alternatively, there could be a RoyalSnark subclass, with an overridden Render method.)

If the purpose is to quickly find all the royal snarks, then a list is more appropriate - otherwise you would need to look at every snark and check its attribute.

Answer 2

That natural way to do it seems to be a property in all cases.

You might use a list for performance, or to optimise space. Both reasons strike me as potential cases of premature optimisation, breaking encapsulation, and/or storing redundant data with the consequent risk of lack of integrity (because I should still be able to query the object itself to find out if it is royal - I shouldn't have to know that this property is handled in a special way for reasons of performance). You could I suppose hide the list implementation behind a getter, to make it behave as a property.

Also, if these objects were stored in a DB, the performance issue pretty much goes away as the DB layer can create the list at runtime using a query anyway.

Answer 3

If you're asking about database modeling, then it's most straightforward to treat is_boojum as an attribute column in the table Snarks. If you need to search for all boojums, the query is simple:

SELECT * FROM Snarks WHERE is_boojum = 1

This gives logically correct answers, and it's easy to model. It might not be so speedy, because indexing a column with low selectivity (many rows with identical values) isn't very efficient, and might not benefit from the index at all.

But your question was about modeling, not optimization.

Answer 4

As a derived class:

class Snark 
{
   virtual void Approach(Creature& approacher) {};
};

class Boojum : public Snark
{
   virtual void Approach(Creature& approacher) 
   { 
      approacher.softlySuddenlyVanishAway(); 
   }
};

Answer 5

Hmmm. My first thought is that, indeed, Boojum is a subtype of Snark. but the specification seems to argue against it, for "the snark was a boojum, you see." Well, that means the snark is_a Boojum, and that would make the inheritance graph cyclic. Can't have that.

On the other hand, I do'nt think there's any indication that a Snark can become a Boojum; either it's a Boojum or it's not.

I think probably you want a Boojum mixin --

abstract class Snark { /*...*/ };
class PlainSnark extends Snark {/*...*/};
class RoyalSnark extends Snark implements Boojum {/*...*/};

Answer 6

I believe that the information entropy associated with the classification can be a guide to which method to use. Low-entropy classifications (i.e. most of the objects have the same value) suggest a list implementation tracking the exceptional cases, while high-entropy classifications (you cannot make any very good predictions about which classification an object will have) suggest a property implementation.