多态VS IF与逻辑 [英] Polymorphism vs if and logic

问题描述

class Person { 
  private state ="normal" //cripple

  run() { 
    if (this.state === "normal") { 
      console.log("run")
    } else {
      console.log("hobble")
    }
  }
}


//vs

abstract class AttemptRun { 
  abstract run();
}


class NormalRun extends AttemptRun { 
  run() { 
    console.log("run")
  }
}

class CrippleRun extends AttemptRun { 
  run() { 
    console.log("hobble")
  }
}

class Person { 
  protected runAbility: AttemptRun;

  run() { 
    this.runAbility.run()
  }
}

假设我理解了这里的概念，这是我的问题。 为什么多态性比IF和逻辑更好。

因为在我看来，你还需要一个工厂或者其他的方法来确定人的能力类型。因此，如果逻辑不在这里，它就会在其他地方。

为什么这在我读过的书中经常重复，比如干净的代码。 它被列为代码气味。

我觉得它可以使单元测试更容易一些，因为这样您只需要测试功能，而不需要测试正在使用它的实际其他类。

这就是它所能提供的全部功能。

如果/否则，您是否需要编写不同的类和工厂？ 看起来很不公平吗？

可能工作量较大，但从长远来看，会更好。

每个案例的弱点是什么？

如果是小班，你会这么做吗？基本上，我不知道我是否理解了这个概念，然后假设我理解了。它的实用性如何。

聪明的开发人员可能只在他们需要特定的东西时才使用它。我不知道任何细节。

推荐答案

您的简单示例中有几点没有演示多态方法的好处。

在您的案例中，只有一个if语句(在Run中)，Person的两个变体，并且每个案例中的行为都非常相似(它们都只是记录一些文本)。

考虑一个更大的情况，其中您拥有更多的功能。如果您添加一个temptToDance，您将引入一个新的if/Else挡路，如果您添加其他变体的Person，则所有函数都需要在现有函数中使用新的if或case。随着您添加更多的功能，您最终会在许多if/Else块中得到许多案例，编译器无法为您验证您没有遗漏其中一个if案例中的Person类型。

用单元测试捕获错误固然很好，但选择一种使错误不可能发生的设计就更好了-编译器从不会错过这样的事情，而且您知道编译器已经运行并正常工作(您希望单元测试运行成功-但您永远不会那么确定)

如果您有一个抽象基类定义了所有类型的Person实现的接口，则编译器将告诉您，如果您未能实现某个派生Person类的方法之一。

在一个更大的实际案例中，每种方法在每种类型的人上的实现可以而且可能会有更大的不同，而不仅仅是输出不同的文本。如果这些都停留在If情况下，所有不同功能最终都集中在一个地方，那么您的代码就会同时依赖于许多东西，这会使测试和维护变得更加困难。如果People类具有方法交互的状态，这会使事情变得更加复杂，并且多态性允许您将该行为包装在一个类中，而无需关注其他类型的Person类。

在简单的情况下，If/Else版本可以工作，只是在许多情况下伸缩性不是很好。

您可能仍需要某个工厂方法中的if/Else或Switch，但只负责构造的一个Switch比许多Switch或if块更容易维护。

这篇关于多态VS IF与逻辑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！