Question

实现第二种情况的唯一要点是，如果我想从一个Collidable派生而不是一个对象？如果是这种情况，那么第一种情况何时有利，因为第二种情况提供了更大的灵活性。

两个collidable只有一个纯虚函数，Object是可以在屏幕上绘制的对象的基类（在我的例子中）。

^假设我正确理解以下代码（我不太确定TBH）

class Object
class CollidableObject : Object
class Actor : public CollidableObject

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

编辑：

基于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

第一个例子是第二个案例，第二个例子是第一个案例。我想这是我在第一种情况下看到的唯一用途。

@Luchian
这将是与原始问题不同的问题，因为您的答复都不是。

在这种情况下，将对象从is-a更改为has-a关系会有区别吗？在每种情况下，为了检查冲突，对象必须有一个标志来知道是否应该检查冲突。在您的情况下，可以检查成员是否为null，但在派生的情况下，对象本身会告诉它是否可以发生碰撞。在数组/树中，我可以将派生对象作为参数传递，或者使用get（）方法将hitbox作为参数传递。

为了更深入，我有另一个类 - 使用第二个案例

class Hitbox : public Object, public Collidable

并且Actor类将其作为成员

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

有碰撞的物体会有一个命中箱，而这正好代表你的帖子。但是我仍然感觉到的是，当我再次回顾你的例子时，是否意味着Hitbox应该有一个Collidable成员呢？

class Hitbox
{
     Collidable *collision;
};

我拥有什么：
一个Actor拥有一个处理碰撞的Hitbox

Hitbox应该做什么：
继承Collidable或
作为会员具有可融合性

演员已经遵循你的约定了。 Hitbox应该做同样的事吗？

Answer 1

我会做第二种情况，因为Object和Collidable是跨领域的问题。如果你走CollidableObject路线，你可能最终会出现类的组合爆炸。不久您就会看到CollidableTrackableClickableBlowuppableObject。

由于Collidable是纯虚拟的，因此在这种情况下它被用作接口，因此没有许多反对多重继承的批评。您只是声明Actor实现了Collidable接口。

Answer 2

这是strategy pattern的完美场景。这就是英语在我们脑海中耍花招的地方，让我们认为CollidableObject是这个等级中的有效对象。我说碰撞更像是一种行为，而不是一种物体，所以我不同意这两种情况。

首选组合物：

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

class AClassThatDoesntCollide
{
   // collisionBehavior = NULL
}

Answer 3

实施第二种情况的唯一要点是我是否想要推导出来从一个没有对象的可碰撞？

是的，第二种情况为您提供了更大的灵活性，因为它允许分离接口。例如，稍后您可能想要一个可以碰撞但不可绘制的对象。

第二个案例提供更多时，第一个案例是否有利灵活性。

第二种情况提供了更大的灵活性，但设计也更复杂。最后，您将需要虚拟继承，这更难以处理。但是，如果您的基类是纯抽象的，那么它应该不是问题。

您可能会看到this。

更优选哪种类型的继承？

3 个答案: