Rud*_*udy 7 oop design-patterns
我经常发现自己在阅读书籍和文章,概述模式,最佳实践以及如何编写"干净的代码".然而,这些概念中的一些似乎过于设计并且有时模糊了底层问题的本质,使得代码更难以与被建模的问题域相关联.
你经常发现自己重构一段能够支持"模式"的代码吗？您是否遇到过"模式"实际上使代码复杂化或模糊其含义的情况？在看到一个问题的解决方案后,我用一个简单的类使用lambdas和闭包重写了解决了这种方式.
我很挣扎,我很好奇其他人如何找到合适的平衡点.
Jur*_*uri 16
你永远不应该重构你的代码只是为了使它适合你在某本书中读到的模式.
模式确实可以帮助您在思考良好的软件设计方面训练您的大脑.我实际上会说,通过阅读模式书并反思它们并学习理解它们如何运作以及它们会给你带来什么好处,我获得了很多编程技巧和知识.这实际上是关键.他们的目的是让事情变得更容易,更易于维护,更容易测试等......不要让你的生活更加艰难:)
我认为这也是"困难".模式为您提供一个框架,一个从遇到问题时开始的点.示例:您确实希望对代码进行单元测试,但是您无法进行单元测试,因为它依赖于UI逻辑或者耦合太多.这是你的问题,所以你可以通过了解MVC模式以及依赖注入和IOC的概念来获得解决方案.他们可能会给你一个起点,因为MVC例如解释了Observer,Observable,Controller视图等的高级概念......以及它们如何相互关联.然后,作为一名优秀的程序员,您可以选择正确的方法,以及您认为应用该模式的合理范围.不要只是应用它,因为模式告诉你.请记住,它只是一个框架,您可以修改和调整它,它适合您的具体情况.
我的建议是尽可能长时间保持您的设计 - 不牺牲可维护性.
基于良好模式的面向对象设计具有许多小型,非常专业的类.最简单的功能可以触及许多类.这使得学习/理解设计变得耗费时间.这种"良好因素"的优点是代码是可维护的 - 小的需求变化通常需要小的本地化代码更改.
系统越不复杂,您就越容易通过简单的设计逃脱.但随着系统变得越来越大,越来越复杂,为了可维护性,这种权衡转向更复杂的设计.