"È una" relazione o, in altre parole, Eredità

1

Dire che definisco un'interfaccia IAnimal che ha un metodo virtuale puro (astratto) chiamato mangiare in questo modo:

class IAnimal
{
   virtual void eat(Food*) = 0;
};

In futuro erediterò la forma IAnimal e creo diversi animali. e alla fine scopro che alcuni animali hanno bisogno non solo di cibo da mangiare ma anche di altre cose. Dì nel mio contesto, (è facile immaginare che sia un gioco), Dog s può mangiare se c'è un Food e un Plate . Man s può mangiare se c'è un Food , Plate , Table e Chair . Significa che è sbagliato utilizzare ereditare da IAnimal ? Possiamo dire che Dog e Man non sono animali poiché non puoi usarli in modo intercambiabile.

    
posta Narek 20.08.2015 - 10:13
fonte

1 risposta

6

Cercare di ottenere una tassonomia accurata degli oggetti del mondo reale che si desidera rappresentare con una gerarchia di classi non è di solito così produttivo. Le tue interfacce dovrebbero rappresentare funzionalità o comportamento piuttosto che categorie ontologiche, perché è ciò che sono le interfacce: una o più funzioni che puoi chiamare.

In altre parole, dai un nome all'interfaccia IEater invece di IAnimal , e questo problema scompare semplicemente, poiché tutto ciò che ha un metodo eat() è chiaramente in grado di mangiare.

Riguardo ai tuoi esempi di oggetti aggiuntivi, è possibile che eat(Food, Plate) sia un caso speciale del più generale eat(Food, Plate, Table, Chair) , ma è anche possibile che questi siano due tipi di mangiare completamente diversi che non dovrebbero essere raggruppati insieme. Dipende interamente da cosa significa mangiare nel contesto della tua applicazione. Se sono completamente diversi, non aver paura di scegliere nomi più espliciti e descrittivi come IPlateEater o IEaterWithTableManners .

    
risposta data 20.08.2015 - 11:23
fonte

Leggi altre domande sui tag