Quale tipo di eredità è più preferibile?

Question

L'unico punto per implementare il secondo caso è se voglio derivare da un Collidable senza essere un oggetto? Se questo è il caso, quando è il primo caso mai favorevole dal momento che il secondo caso offre maggiore flessibilità.

Entrambi gli oggetti collidabili hanno solo una funzione virtuale pura e Object è una classe base per oggetti che possono essere disegnati sullo schermo (nel mio caso).

^Supponendo che io sto capendo il seguente codice correttamente (io non sono troppo sicuro TBH)

class Object 
class CollidableObject : Object 
class Actor : public CollidableObject 

class Object 
class Collidable 
class Actor : public Object, public Collidable 

Edit:

Sulla base di Matt/Seth

class Object 
class Collidable 
class Clickable 
class Trackable 
class BlowUppable 
class Actor : public Object, public Collidable, public Clickable, public Trackable, 
       public BlowUppable 

class SomeObjectThatIsTakenForGrantedThatEverythingElseIsInherited : public Actor 

Primo esempio è il secondo caso e il secondo esempio è il primo caso. Immagino che questo sia l'unico uso che vedo per il primo caso.

@Luchian
Questa sarà una domanda diversa dall'originale poiché la tua risposta non è stata né l'una né l'altra.

In questo caso, c'è una differenza nel cambiare un oggetto da una relazione is-a a ha-a? In ogni caso, per verificare la presenza di collisioni, un oggetto deve avere una bandiera per sapere se la collisione deve essere controllata. Nel tuo caso, il membro può essere controllato se è nullo o no, ma nel caso derivato, l'oggetto stesso dice se può scontrarsi o meno. In una matrice/albero, posso passare l'oggetto derivato come argomento o passare l'hitbox come argomento usando un metodo get().

Per essere più in profondità, ho un'altra classe - utilizzando il secondo caso

class Hitbox : public Object, public Collidable 

e la classe attore ha come membro

class Actor : public Object 
{ 
    Hitbox *box; 
}; 

oggetti che hanno collisione avrebbe un hitbox invece e questo rappresenta il tuo post con precisione penso. Ma quello che mi sta ancora facendo è che quando ripasso il tuo esempio, vuol dire che Hitbox dovrebbe avere un membro Collidable?

class Hitbox 
{ 
    Collidable *collision; 
}; 

Quello che ho:
Un attore detiene una Hitbox che gestisce collisione

Cosa Hitbox dovrebbe fare:
Eredita Collidable o
Hanno Collidable come membro

attore sta già seguendo la tua convention Hitbox dovrebbe fare lo stesso?

Answer 1

Vorrei fare il secondo caso, come Object e Collidable sono preoccupazioni trasversali. Se segui il percorso CollidableObject, probabilmente finirai con un'esplosione combinatoria di classi. Non passerà molto tempo finché non vedi un CollidableTrackableClickableBlowuppableObject.

Poiché Collidable è puro virtuale, è utilizzato in questo caso come interfaccia, quindi non ha molte delle critiche che discutono contro l'ereditarietà multipla. Stai semplicemente affermando che un attore implementa l'interfaccia Collidable.

Answer 2

Questo è uno scenario perfetto per strategy pattern. È qui che la lingua inglese gioca brutti scherzi e ci fa pensare che CollidableObject sia un oggetto valido da avere in questa gerarchia. Dico che la collisione è più un comportamento che un oggetto, quindi non andrei con nessuno dei due.

Preferisco composizione per questo:

class Object 
{ 
    CollidableBehavior* collisionBehavior; 
} 
class Actor : Object 
{ 
    // collisionBehavior = new ActorCollision() 
} 

class AClassThatDoesntCollide 
{ 
    // collisionBehavior = NULL 
} 

Answer 3

è l'unico punto nell'attuazione del secondo caso è se voglio ricavare da un Collidable senza essere un oggetto?

Sì, il secondo caso offre maggiore flessibilità in quanto consente di separare le interfacce. Ad esempio, in un secondo momento potresti volere un oggetto che è collidabile ma non è disegnabile.

Quando il primo caso è mai favorevole dal momento che il secondo caso offre più flessibilità .

Il secondo caso offre maggiore flessibilità ma è anche più complesso da progettare. Alla fine, avrai bisogno di ereditarietà virtuale e questo è più difficile da gestire. Tuttavia, se le classi di base sono puramente astratte, non dovrebbe essere un problema.

Si può vedere this.