language-agnostic - OOP:何时创建派生类，何时使用条件实现功能？

Question

我什么时候应该继续创建派生类，什么时候应该在我的代码中添加条件？
例如导弹

class Object;
class Projectile : public Object;

class Missile : public Projectile;
class MissileGuided : public Missile;

还是我应该在导弹代码中实现最后一个？

void Missile::Update()
{
    if(homing && ObjectExists(Target))
        TurnTowards(Target.Pos)

    Pos += Motion;
}

我认为对于所有更精细的细节，第二个更好，因为您开始获得事物的组合(例如，有些导弹可能不会在雷达上显示，有些可能是可摧毁的，如果原始导弹被摧毁，有些可能会获得新目标或超出范围等)

然而，在某些情况下，对于共享导弹特性的常规射弹也可以这样说(例如，可能是可摧毁的，大型射弹可能会出现在雷达上等)

然后我可以进一步说，射弹与船只共享属性(两者都会移动，碰撞时会造成伤害，可能会在雷达上显示，可能会被摧毁......)

然后一切都像 3 类一样结束:

class Entity;
class Object : public Entity;
class Effect : public Entity;

在创建派生类和使用标志或其他东西实现方法中的功能之间划清界限的好点在哪里？

Answer 1

您可能需要考虑使用 策略格局而不是方法和封装外部类中的行为。然后可以将这些行为注入(inject)到 Missile 类中，使其成为 GuidedMissile 或 SpaceRocket 或您需要的任何其他东西。

这样可以避免 Missile 类中逻辑的过度分支，并且您不需要进入与深度继承相关的逻辑复杂性。

Wikipedia 收集了多种语言的模式使用示例:
http://en.wikipedia.org/wiki/Strategy_pattern

interface INavigable {
  Course calcCourse (Position current, Destination dest);
}


Class GeoStationaryRocketCPU implements INavigable {
  Course calcCourse (Position current, Destination dest) {
     return dest.getShortestRouteTo (current).getCourse();
  };

}

Class GuidedMissileCPU implements INavigable {
  Course calcCourse (Position current, Destination dest) {
      return dest.getLowestAltRouteTo (current).getCourse();
  };

}



class Missile {
  INavigable CPU;

  void setCPU (INavigable CPU) {
     this.CPU = CPU;
  }

  void fly ()
  {

     ...
     course = this.CPU.calcCourse (pos, dest);
     ...
  }

}

正如另一位同事所建议的，您也可以考虑使用装饰器模式。只是为了突出几个设计问题，如果你要走这条路，这些问题在你的环境中可能很重要:

要仅替换对象行为的某个方面，您需要装饰整个类。

如果装饰类(比如说导弹)的公共(public)接口(interface)被改变(甚至是一些与其导航方面无关的功能)，你将不得不改变所有的装饰类(即 GuidedMissile、Rocket、FireworkRocket 等)以传递界面。

在装饰器中，您会期望装饰器会添加功能，而不是替换它。它通过添加调用其函数然后调用基类方法来工作。在上面的场景中，这将导致能够拥有一个装饰 GeoStationaryRocketCPU 的 GuidedMissileCPU——显然这不是你想要的。您希望它选择一种不同的导航策略，而不是将导航策略叠加在一起。

尽管如此，当提供一个现成的不可变的导弹装饰实现时，可能是“解锁”它并实现策略模式的关键，为导弹提供各种所需的行为。