如何理解If-Else是贫瘠的多态性问题

这篇文章主要讲解了"如何理解If-Else是贫瘠的多态性问题"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"如何理解If-Else是贫瘠的多态性问题"吧！

笔者常常看到许多分支发生在枚举或其他离散值上，当某些开发人员被要求不要使用if-then-else时，甚至会感到恼火。if-else和switch当然可以生成简洁的代码，你的软件不应该由最少的行组成，也不必牺牲可读性、可维护性或灵活性。

在if-then-else语句中使用枚举的后果是什么呢?基于离散值的分支会使软件难以更改。每个新功能都要求跟踪分支发生的位置，并相应地修改现有代码。

这绝对不是我们想要的方式。这或许是使代码正常工作的第一步，但随着你不断改进代码，switch和if-then-else肯定早已不复存在。

我必须要说，使用if-else和switch进行分支的传统方法已过时。它不可靠、不灵活。传统方法中没有面向对象的内容。但是它仍在蓬勃发展，因为学生们被迫认为它是正确的，甚至是最佳实践。代码是有效的，但你可以做得更好。

设想一下这个问题。假设出于某种原因，必须用一种方法来更新用户。为了简单起见，用户只出于两种理由需要在系统中被更新。

最初的一组要求

你可以在以下代码段中实现这两种简单的情况。花一点时间阅读这段设计欠佳的代码吧，许多高级开发人员都把此当作噩梦，它甚至被认为是引发"十年怕井绳"的那条蛇。

是的，我看到过这样疯狂的野生代码。这是一个非常幼稚的操作，它假定用户永远没有那么多理由进行更改了。

无用if-else指令的可怕代码示例

此代码唯一好处是可以尝试实现一种半CQS式的设计模式。如果你倾向于说"那就应该是一个switch"，那你应该花点时间思考一下软件开发中到底什么是重要的。Switch对if-else来说完全无关紧要。

你每时每刻都会受到新要求的打击，谁曾想到呢?你曾以为不会发生任何事情。对你的要求现在是这样的：

你是否真的要通过添加其他枚举值并附加两个else-if语句来实现这两个新原因下的用户更新?如果决定走这条错路，结果就会是下面这样。

复杂的、令人头痛的分支

这种实现本质上是贫瘠的多态性。除了不断地添加额外的分支(这本身是一个值得怀疑的实践)之外，每当需要调试或执行错误修复时，都会被完全无关的代码包围。

还有一个问题。这个方法标记正在欺骗我们，因为它不只是更新用户。它还根据更新原因选择执行哪种算法，甚至知道每种实现。现在显而易见，这种方法负有大量责任。

我相信这个例子加深了一切关于if-else和switch的可怕印象。让我们看看如何避免这种讨厌的方法。

重构为多态执行非常容易。把基于分支的凌乱代码重构为内聚的、简单的、吻合实际需求的类。在有人说害怕使用类之前，笔者要先澄清一件事。实例化新类的成本通常可以忽略不计，在遇到瓶颈之前，请不要尝试优化代码。

我们可以做得更好，可以编写可读的、可维护的、灵活的代码。通过用多态执行代替传统的分支，类与它管理的需求之间有了明确的联系。具有明确职责的简单、高度凝聚力的类易于维护。检测和纠正缺陷变得轻而易举。最重要的是，软件可以轻松容纳新功能，而无需修改现有类。

让我们开始重构。来看看不使用if-then-else或switch能做得多好。UpdateAsync(Reason，User)现在变得如此简单。

简化的UpdateAsync方法实现

请注意，你现在使用的是接口参数而不是枚举。现在，该方法委托了知道如何对特定对象执行更新的职责。IUpdateReason的具体实现如下所示，构造函数参数和方法实现的细节不多做赘述。

UpdateReason接口及其具体实现

每个类都完全符合其管理的要求。与过时方法相比，调试，修复错误和测试现在要容易多。在这种情况下，任何新要求都会产生一个专门的类。

我们可以轻松地停在这里，结束一天的工作。你重构了繁琐的分支，并将其替换为多态。你的代码现在是面向对象的，并且易于维护。但也可以选择进行最后一步。UpdateAsync(Reason，User)现在有些多余。为了解决这个问题，我们不再进行重构——我们正在重新设计系统的各个部分。

在这种情况下，创建命令对象和命令处理程序是有意义的。它将简化调用代码，因为它只调度了诸如UpdateUserAddress之类的命令，并且将调用相应的处理程序的操作

感谢各位的阅读，以上就是"如何理解If-Else是贫瘠的多态性问题"的内容了，经过本文的学习后，相信大家对如何理解If-Else是贫瘠的多态性问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！