Certains snarks sont des boojums: liste de boojums, ou propriété is_boojum sur tous les snarks?

Question

Le domaine de problème comporte une grande population de snarks nommés. Certains des snarks sont des boojums.

Il y a au moins deux façons de modéliser ce:

 
// 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; 

Il semble intuitif que si nous avons déterminé que snarks viennent chez le mâle et la femelle, nous ajouterons une propriété « sexe » à la définition de la classe snark; et si nous déterminions que tous sauf cinq snarks étaient des sujets vaincus, nous ferions une liste de royals.

Y a-t-il des principes que l'on peut appliquer ou est-ce une question de préférence architecturale?

Answer 1

Je crois que l'entropie de l'information associée à la classification peut être un guide pour la méthode à utiliser. Les classifications à faible entropie (la plupart des objets ont la même valeur) suggèrent une implémentation de la liste qui suit les cas exceptionnels, tandis que les classifications à forte entropie (vous ne pouvez pas faire de très bonnes prédictions sur la classification d'un objet).

Answer 2

Quel problème essayez-vous de résoudre? Si le but de l'enregistrement de la redevance des snarks est d'afficher une couronne sur leurs têtes dans le GUI, alors il est logique que ce soit simplement un attribut. (Alternativement, il pourrait y avoir une sous-classe RoyalSnark, avec une méthode Render substituée.)

Si le but est de trouver rapidement tous les snarks royaux, alors une liste est plus appropriée - sinon vous auriez besoin de regarder tous les snark et vérifiez son attribut.

Answer 3

Cette façon naturelle de le faire semble être une propriété dans tous les cas.

Vous pouvez utiliser une liste pour les performances ou pour optimiser l'espace. Les deux raisons me semblent être des cas potentiels d'optimisation prématurée, de rupture de l'encapsulation et/ou de stockage de données redondantes avec le risque de manque d'intégrité qui en découle (car je devrais être capable d'interroger l'objet lui-même il faut savoir que cette propriété est gérée d'une manière spéciale pour des raisons de performance). Vous pourriez je suppose cacher l'implémentation de liste derrière un getter, pour le faire se comporter comme une propriété.

De plus, si ces objets étaient stockés dans une base de données, le problème de performance disparaît car la couche DB peut créer la liste lors de l'exécution à l'aide d'une requête.

Answer 4

Si vous vous interrogez sur la modélisation de base de données, il est plus simple de traiter is_boojum comme une colonne d'attribut dans la table Snarks. Si vous devez rechercher tous boojums, la requête est simple:

SELECT * FROM Snarks WHERE is_boojum = 1 

Cela donne des réponses logiquement correctes, et il est facile à modéliser. Cela peut ne pas être si rapide, car l'indexation d'une colonne avec une faible sélectivité (plusieurs lignes avec des valeurs identiques) n'est pas très efficace et peut ne pas bénéficier du tout de l'index. Mais votre question portait sur la modélisation, pas sur l'optimisation.

Answer 5

En tant que classe dérivée:

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

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

Answer 6

Hmmm. Ma première pensée est que, en effet, Boojum est un sous-type de Snark. mais la spécification semble s'opposer à cela, car "le snark était un boojum, voyez-vous". Eh bien, cela signifie que le snark est_a Boojum, et que cela rendrait le graphe d'héritage cyclique. Je ne peux pas avoir ça.

D'autre part, je do'nt pense qu'il ya une indication qu'un Snark peut devenir un Boojum; soit c'est un Boojum ou pas.

Je pense que probablement vous voulez un mixin Boojum -

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