Eredità andata storta

Ho del codice in cui un buon modello di ereditarietà è andato in discesa e sto cercando di capire perché e come risolverlo. Fondamentalmente, immagina di avere una gerarchia Zoo con:

class Animal  
class Parrot : Animal 
class Elephant : Animal 
class Cow : Animal

eccetera.

Hai i tuoi metodi eat (), run (), ecc. E tutto va bene. Poi un giorno qualcuno arriva e dice: la nostra classe CageBuilder funziona alla grande e usa animal.weight () e animal.height (), ad eccezione del nuovo bisonte africano che è troppo forte e può mandare in frantumi il muro, quindi aggiungerò un'altra proprietà per la classe Animal - isAfricanBizon () e usala quando scegli il materiale e lo ignori solo per la classe AfricanBizon. La persona successiva arriva e fa qualcosa di simile e la prossima cosa che sai di avere tutte queste proprietà specifiche per alcuni sottogruppi della gerarchia nella classe base.

Qual è un buon modo per migliorare / refactoring tale codice? Un'alternativa qui sarebbe usare solo dynamic_casts per verificare i tipi, ma ciò ingombra i chiamanti e aggiunge un sacco di if-then-else in tutto il luogo. Puoi avere interfacce più specifiche qui, ma se tutto ciò che hai è il riferimento della classe base che non aiuta molto. Altri suggerimenti? Esempi?

Grazie!

Sembra che il problema sia invece di implementare RequistConcreteWall (), hanno implementato una chiamata flag IsAfricanBison () e quindi spostato la logica sull'opportunità o meno di modificare il muro al di fuori dell'ambito della classe. Le tue classi dovrebbero esporre comportamenti e requisiti, non identità; i tuoi consumatori di queste classi dovrebbero lavorare in base a ciò che viene loro detto, non in base a ciò che sono.

isAfricanBizon () non è generico. Supponiamo che estendi la tua fattoria con un ippopotamo che sia anche troppo forte ma che ritorni vero da isAfricanBizon () per avere l'effetto giusto sarebbe semplicemente sciocco.

vuoi sempre aggiungere metodi all'interfaccia che rispondano alla domanda specifica, in questo caso sarebbe qualcosa di simile a forza ()

Penso che il tuo problema sia questo: hai vari client della libreria che sono interessati solo a un sottoinsieme della gerarchia ma a cui viene passato un puntatore / riferimento alla classe base. Questo è in effetti il ​​problema che dynamic_cast <> è lì per risolvere.

È una questione di progettazione dei client ridurre al minimo l'uso di dynamic_cast <>; dovrebbero usarlo per determinare se l'oggetto richiede un trattamento speciale e in tal caso tutte le operazioni sul riferimento verso il basso.

Se si dispone di raccolte di funzionalità "mix-in" che si applicano a più sotto-gerarchie separate, è possibile utilizzare il modello di interfaccia utilizzato da Java e C #; avere una classe di base virtuale che è una classe pura-virtuale e utilizzare dynamic_cast <> per determinare se un'istanza fornisce un'implementazione per essa.

Una cosa che puoi fare è sostituire il controllo esplicito del tipo come isAfricanBison()con il controllo delle proprietà che ti interessano, ad es isTooStrong().

Gli animali non dovrebbero preoccuparsi dei muri di cemento. Forse puoi esprimerlo con valori semplici.

class Animal {
public:
  virtual ~Animal() {}
  virtual size_t height() const = 0;
  virtual size_t weight() const = 0;
  virtual bool isStrong() const = 0;
};

Cage *CreateCageFromSQL(Animal &a);
Cage *CreateCageFromOrangePeelsAndSticks(Animal &a);

Sospetto però che non sia fattibile. Questo è il problema con esempi di giocattoli, però.

In ogni caso, non vorrei mai vedere RequistConcreteWalls () o linee e linee di lanci di puntatori dinamici.

Questa è di solito una soluzione economica . È facile da mantenere e concettualizzare. E davvero, il problema afferma che è comunque legato al tipo di animale.

class Animal {
public:
  virtual ~Animal() {}
  virtual CageBuilder *getCageBuilder() = 0;
};

Questo non ti preclude nemmeno l'uso del codice condiviso, inquina solo un po 'Animal.

Ma come viene costruita la gabbia può essere una politica di qualche altro sistema e forse hai più di un tipo di generatore di gabbie per animale. Ci sono molte combinazioni strane e contorte che puoi inventare.

Ho usato il Component Based Design per fini positivi, il problema principale è che può essere problematico quando la proprietà di Animal è condivisa. Come evitare il lancio di distruttori è il punto dolente.

Double Dispatch è un'altra opzione, anche se sono sempre stato reticente a saltarci dentro.

Oltre a ciò, è difficile indovinare il problema.

Bene sicuramente tutti gli animali hanno la proprietà intrinseca di attemptEscape(). Mentre alcuni il metodo può comportare un falserisultato in tutti gli scenari, mentre altri possono avere una possibilità basata sull'euristica delle loro altre caratteristiche intrinseche come sizee weight. Quindi sicuramente ad un certo punto attemptEscape()diventa banale in quanto sicuramente ritornerà true.

Temo di non capire completamente la tua domanda però ... tutti gli animali hanno azioni e caratteristiche correlate. Quelli specifici per l'animale dovrebbero essere introdotti dove è appropriato. Cercare di mettere in relazione diretta Bison con Parrots non è una buona configurazione di ereditarietà e non dovrebbe davvero essere un problema in una progettazione corretta.

Un'altra opzione sarebbe quella di utilizzare una fabbrica che crea gabbie appropriate per ogni animale. Penso che questo possa essere migliore nel caso in cui le condizioni siano molto diverse per ciascuno di essi. Ma se è solo questa condizione il RequiresConcreteWall()metodo sopra menzionato lo farà.

che ne dici di AdviceCageType () rispetto a RequistConcreteWall ()

Perché non fare qualcosa del genere

class Animals { /***/ } class HeavyAnimals{} : Animals //The basic class for animals like the African Bison

Con la classe HeavyAnimals puoi creare la classe African Bison estendendo la classe HeavyAnimals.

Quindi ora puoi utilizzare la classe genitore (gli Animali) che puoi usare per creare un'altra classe base come la classe HeavyAnimal con cui puoi creare la classe Bisonte africano e altri animali pesanti. Quindi con il bisonte africano ora hai accesso ai metodi e alle proprietà della classe Animale (questa è la base per tutti gli animali) e l'accesso alla classe HeavyAnimals (questa è la base per gli animali pesanti)