Design orientato agli oggetti

Supponiamo di avere quanto segue:

     +--------+     +------+
     | Animal |     | Food |
     +-+------+     +----+-+
       ^                 ^
       |                 |
       |                 |
  +------+              +-------+
  | Deer |              | Grass |
  +------+              +-------+

Deereredita da Animaled Grasseredita da Food.

Fin qui tutto bene. Animalgli oggetti possono mangiare Foodoggetti.

Ora lasciamo un po 'di confusione. Consente di aggiungere un Lionche eredita da Animal.

     +--------+     +------+
     | Animal |     | Food |
     +-+-----++     +----+-+
       ^     ^           ^
       |     |           |
       |     |           |
  +------+ +------+     +-------+
  | Deer | | Lion |     | Grass |
  +------+ +------+     +-------+

Ora abbiamo un problema perché Lionpossiamo mangiare entrambi Deere Grass, ma Deernon Foodlo è Animal.

Senza utilizzare l'ereditarietà multipla e la progettazione orientata agli oggetti, come si risolve questo problema?

Cordiali saluti: Ho usato http://www.asciiflow.com per creare i diagrammi ASCII.

Relazioni IS A = Ereditarietà

Il leone è un animale

Ha relazioni A = Composizione

L'auto ha una ruota

PU DO FARE relazioni = Interfacce

Posso mangiare

OO è solo una metafora che si modella sul mondo reale. Ma le metafore vanno solo così lontano.

Normalmente non esiste un modo giusto per modellare qualcosa in OO. C'è un modo giusto per farlo per un problema particolare in un determinato dominio e non dovresti aspettarti che funzioni bene se cambi il problema, anche se gli oggetti del dominio sono gli stessi.

Penso che questo sia un malinteso comune più Comp. Ing. gli studenti hanno nei loro primi anni. OO non è una soluzione universale, solo uno strumento decente per alcuni tipi di problemi che possono modellare il tuo dominio ragionevolmente bene.

Non ho risposto alla domanda, proprio perché ci mancano le informazioni sul dominio. Ma tenendo presente quanto sopra potresti essere in grado di progettare qualcosa che si adatta alle tue esigenze.

Vuoi scomporre ulteriormente gli animali nelle loro sottoclassi (o almeno per quanto ha senso per quello che stai facendo). Dato che stai lavorando con quelli che sembrano animali di base e due tipi di cibo (piante e carne), ha senso usare carnivori ed erbivori per definire ulteriormente un animale e tenerli separati. Ecco cosa ho elaborato per te.

             +----------------+                   +--------------------+
             |    Animal      |                   |      Food          |
             |----------------|<--+Interfaces+--->|--------------------|
             |                |                   |                    |
             +----------------+                   +--------------------+
                +           +                       +                 +
                |           |    Abstract Classes   |                 |
                |           |        |          |   |                 |
                v           v        v          v   v                 v
   +-----------------+  +----------------+     +------------+      +------------+
   |   Herbivore     |  |  Carnivore     |     |   Plant    |      |   Meat     |
   |-----------------|  |----------------|     |------------|      |------------|
   |Eat(Plant p)     |  |Eat(Meat m)     |     |            |      |            |
   |                 |  |                |     |            |      |            |
   +-----------------+  +----------------+     +------------+      +------------+
            +                    +                    +                   +
            |                    |                    |                   |
            v                    v                    v                   v
   +-----------------+  +----------------+     +------------+      +------------+
   |  Deer           |  |   Lion         |     |  Grass     |      |  DeerMeat  |
   |-----------------|  |----------------|     |------------|      |------------|
   |DeerMeat Die()      |void Kill(Deer) |     |            |      |            |
   +-----------------+  +----------------+     +------------+      +------------+
                                 ^                    ^
                                 |                    |
                                 |                    |
                              Concrete Classes -------+

Come puoi vedere, entrambi espongono un metodo alimentare, ma ciò che mangiano cambia. Il leone può ora uccidere un cervo, il cervo può morire e restituire DeerMeat, e la domanda originale di OP su come consentire a un leone di mangiare un cervo ma non si risponde all'erba senza progettare un intero ecosistema.

Naturalmente, questo diventa interessante molto rapidamente perché un cervo potrebbe essere considerato anche un tipo di carne, ma per mantenere le cose semplici, creerei un metodo chiamato kill () sotto i cervi, che restituisce una carne di cervo, e lo metto come classe concreta che estende la carne.

Il mio design sarebbe così:

1. Gli alimenti sono dichiarati come interfacce; c'è un'interfaccia IFood e due interfacce derivate da essa: IMeat e IVegetable
2. Gli animali implementano IMeat e gli ortaggi implementano IVegetable
3. Gli animali hanno due discendenti, carnivori ed ebivori
4. I carnivori hanno il metodo Eat che riceve un'istanza di IMeat
5. Gli erbivori hanno il metodo Eat che riceve un'istanza di IVegetable
6. Il leone discende dal carnivoro
7. Il cervo discende da Erbivoro
8. L'erba scende dalla verdura

Poiché gli animali implementano IMeat and Deer è un (Herbivore) Animal, Lion, che è un (Carnivore) Animal che può mangiare IMeat può anche mangiare Deer.

Il cervo è un erbivoro, quindi può mangiare erba perché implementa IVegetable.

I carnivori non possono mangiare IVegeable e gli erbivori non possono mangiare IMeat.

Quali alimenti un animale può effettivamente non formare una gerarchia, in questo caso la natura non è riuscita a conformarsi ingiustificatamente alla semplice modellizzazione orientata agli oggetti (si noti che anche se lo facesse, l'animale dovrebbe ereditare dal cibo, dal momento che è cibo).

La conoscenza di quali alimenti un animale può mangiare non può vivere interamente con nessuna delle classi, quindi semplicemente avere un riferimento ad un membro della gerarchia alimentare non può essere sufficiente per dirti quali cose puoi mangiare.

È una relazione da molte a molte. Ciò significa che ogni volta che aggiungi un animale, devi capire cosa può mangiare e ogni volta che aggiungi un cibo, devi capire cosa può mangiarlo. La presenza di ulteriori strutture da sfruttare dipende dagli animali e dagli alimenti che stai modellando.

L'ereditarietà multipla non risolve davvero molto bene neanche questo. Hai bisogno di una sorta di raccolta di cose che un animale può mangiare o di animali che possono mangiare un cibo.

Affronterò il problema da un'altra parte: OOP riguarda il comportamento. Nel tuo caso, Grassha qualche comportamento di cui essere figlio Food? Quindi, nel tuo caso, non ci sarà Grassclasse, o almeno, non sarà ereditato Food. Inoltre, se devi imporre a chi può mangiare cosa in fase di compilazione, è discutibile se hai bisogno di Animalastrazione. Inoltre, non è raro vedere i carnivori che mangiano erba , anche se non per il sostentamento.

Quindi progetterei questo come (non mi preoccuperò con l'arte ASCI):

IEdiblecon proprietà Type, che è enum di carne, piante, carcasse, ecc. (questo non cambia spesso e non ha alcun comportamento specifico, quindi non è necessario modellarlo come classe hiearchy).

Animalcon metodi CanEat(IEdible food)e Eat(IEdible food), che sono logici. Quindi, specifici animali possono controllare ogni volta che possono mangiare cibo dato in determinate circostanze e quindi mangiare quel cibo per ottenere sostentamento / fare qualcos'altro. Inoltre, modellerei le classi Carnivore, Herbivore, Omnivore come modello di strategia , piuttosto che come parte della gerarchia animale.

TL; DR: progettazione o modello con un contesto.

Penso che la tua domanda sia difficile perché manca il contesto del problema reale che stai cercando di risolvere. Hai alcuni modelli e alcune relazioni, ma manca il quadro in cui deve funzionare. Senza contesto, la modellazione e le metafore non funzionano bene lasciando la porta aperta a più interpretazioni.

Penso che sia più produttivo concentrarsi su come verranno consumati i dati. Una volta che hai il modello di utilizzo dei dati, è più facile tornare indietro a ciò che dovrebbero essere i modelli e le relazioni.

Ad esempio requisiti più dettagliati richiederanno relazioni oggetto diverse:

• sostenere Animals eatil non- FoodlikeGastroliths
• sostenere Chocolatecome Poisonper Dogs, ma non perHumans

Se iniziamo con l'esercizio di come modellare la semplice relazione presentata, l'interfaccia alimentare potrebbe essere la migliore; e se questa è la somma totale delle relazioni nel sistema, allora va bene. Tuttavia, solo alcuni requisiti o relazioni aggiuntivi possono influenzare notevolmente i modelli e le relazioni che hanno funzionato nel caso più semplice.

Approccio basato sulla composizione per ereditarietà:

An entity is a collection of components.
Systems process entities through their components.

Lion has claws and fangs as weapons.
Lion has meat as food.
Lion has a hunger for meat.
Lion has an affinity towards other lions.

Deer has antlers and hooves as weapons.
Deer has meat as food.
Deer has a hunger for plants.

Grass has plant as food.

pseudocodice:

lion = new Entity("Lion")
lion.put(new Claws)
lion.put(new Fangs)
lion.put(new Meat)
lion.put(new MeatHunger)
lion.put(new Affinity("Lion"))

deer = new Entity("Deer")
deer.put(new Antlers)
deer.put(new Hooves)
deer.put(new PlantHunger)

grass = new Entity("Grass")
grass.put(new Plant)

Natureè un systemciclo che scorre attraverso queste entità, cercando quali componenti hanno attraverso una funzione di query generalizzata. Naturefarà sì che entità affamate di carne attaccino altre entità che hanno carne come cibo usando le loro armi, a meno che non abbiano un'affinità con quell'entità. Se l'attacco ha successo, l'entità si nutrirà della sua vittima, a quel punto la vittima si trasformerà in un cadavere privo di carne. Naturefarà sì che le entità affamate di piante si nutrano di entità che hanno piante come cibo, a condizione che esistano.

Nature({lion, deer, grass})

Nature(entities)
{
    for each entity in entities:
    {
       if entity.has("MeatHunger"):
           attack_meat(entity, entities.with("Meat", exclude = entity))
       if entity.has("PlantHunger"):
           eat_plants(entity, entites.with("Plant", exclude = entity))
    }
}

Forse vogliamo estenderci Grassper avere bisogno della luce solare e dell'acqua e vogliamo introdurre la luce solare e l'acqua nel nostro mondo. Tuttavia, Grassnon è possibile cercarli direttamente, poiché non è cosìmobility . Animalspuò anche aver bisogno di acqua, ma può cercarla attivamente poiché hanno mobility. È abbastanza facile continuare a estendere e modificare questo modello senza interrompere a cascata l'intero progetto, poiché aggiungiamo solo nuovi componenti ed estendiamo il comportamento dei nostri sistemi (o il numero di sistemi).

Senza utilizzare l'ereditarietà multipla e la progettazione orientata agli oggetti, come si risolve questo problema?

Come la maggior parte delle cose, dipende .

Dipende da cosa che vedi "questo problema".

• E 'un problema di implementazione generale , ad esempio come "aggirare" l'assenza di ereditarietà multipla nella piattaforma prescelta?
• È un problema di progettazione solo per questo caso specifico , ad esempio come modellare il fatto che anche gli animali sono cibo?
• E 'un problema filosofico con il modello di dominio , ad esempio "classificazioni alimentari" e "animali" valide, necessarie e sufficienti per l'applicazione pratica prevista?

Se stai chiedendo del problema generale di implementazione, la risposta dipenderà dalle capacità del tuo ambiente. Le interfacce IFood e IAnimal potrebbero funzionare, con una sottoclasse EdibleAnimal che implementa entrambe le interfacce. Se il tuo ambiente non supporta le interfacce, crea l'eredità degli animali dagli alimenti.

Se stai chiedendo di questo specifico problema di progettazione, fai semplicemente ereditare gli animali dal cibo. È la cosa più semplice che potrebbe funzionare.

Se stai chiedendo di questi concetti di design, la risposta dipende fortemente da cosa intendi fare con il modello. Se è per un videogioco cane-mangia-cane o anche un'applicazione per tenere traccia dei programmi di alimentazione in uno zoo, potrebbe essere sufficiente per funzionare. Se è per un modello concettuale per i modelli comportamentali degli animali, è probabilmente un po 'superficiale.

L'ereditarietà dovrebbe essere usata per qualcosa che è sempre qualcos'altro e che non può cambiare. L'erba non è sempre cibo. Ad esempio, non mangio erba.

L'erba svolge il ruolo di alimento per alcuni animali.

Hai appena incontrato il limite di base di OO.

OO funziona bene con strutture gerarchiche. Ma una volta che ti allontani da rigide gerarchie, l'astrazione non funziona così bene.

Conosco tutto sulle composizioni di metamorfosi, ecc. Che vengono utilizzate per aggirare queste limitazioni ma sono goffe e, soprattutto, portano a codici oscuri e difficili da seguire.

Le basi dati relazionali sono state inventate principalmente per allontanarsi dai limiti delle rigide strutture gerarchiche.

Per fare un esempio, l'erba potrebbe anche essere un materiale da costruzione, una materia prima per la carta, un materiale per l'abbigliamento, un'erbaccia o un raccolto.

Un cervo potrebbe essere un animale domestico, un bestiame, un animale da zoo o una specie protetta.

Un leone potrebbe anche essere un animale da zoo o una specie protetta.

La vita non è semplice

Senza utilizzare l'ereditarietà multipla e la progettazione orientata agli oggetti, come si risolve questo problema?

Che problema? Cosa fa questo sistema? Fino a quando non risponderai, non ho idea di quali classi possano essere richieste. Stai cercando di modellare un'ecologia, con carnivori, erbivori e piante, proiettando popolazioni di specie nel futuro? Stai cercando di far giocare 20 domande al computer?

Iniziare la progettazione è una perdita di tempo prima che siano definiti tutti i casi d'uso. L'ho visto portato a livelli ridicoli quando una squadra di circa dieci ha iniziato a produrre un modello OO di una compagnia aerea usando il software attraverso le immagini. Hanno lavorato per due anni a modellare senza alcun problema aziendale in mente. Alla fine il cliente si stancò di aspettare e chiese al team di risolvere un problema reale. Tutta quella modellistica era completamente inutile.