这篇文章主要讲解了“如何理解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是贫瘠的多态性问题这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!