gpt4 book ai didi

oop - 多态与 if 和逻辑

转载 作者:行者123 更新时间:2023-12-04 17:15:53 25 4
gpt4 key购买 nike

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/else 而不是您需要编写不同的类和工厂?
似乎不公平?

也许这是更多的工作,但从长远来看,它会更好。

每个案例的弱点是什么?

如果是小类,你会这样做吗?基本上,我不知道我是否理解这个概念,然后假设我理解。使用起来有多实用。

明智的开发人员可能仅在需要特定内容时才使用它。我不知道任何细节。

最佳答案

关于您的简单示例,有几件事并未证明多态方法的好处。

在您的情况下,只有一个 if 语句(运行中),只有 2 个 person 变体,每种情况下的行为都非常相似(它们都只记录一些文本)。

考虑一个更大的情况,虽然你有更多的功能。如果您添加一个尝试舞蹈,您将引入一个新的 if/else block ,如果您添加其他人的变体,您的所有函数都需要在现有函数中添加一个新的 if 或 case。随着您添加更多功能,您最终会在许多 if/else block 中遇到许多情况,并且编译器无法为您验证您没有错过 if 案例中的一种人员类型。

用单元测试捕捉错误很棒,但选择一个使错误不可能发生的设计更好——编译器永远不会错过这样的事情,而且你知道编译器运行并工作(你希望单元测试成功运行——但是你'从来没有那么确定)

如果您有一个抽象基类定义了一个所有类型的人员都实现的接口(interface),那么编译器将告诉您您是否未能为派生的人员类之一实现其中一种方法。

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

在简单的情况下,if/else 版本可以工作,但在许多情况下它的扩展性不是很好。

您可能仍然需要在某个工厂方法中使用 if/else 或 switch,但是一个只负责构造的 switch 比许多 switch 或 if block 更容易维护。

关于oop - 多态与 if 和逻辑,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47402390/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com