也许我的问题在性质上与此类似:你是否使用设计模式？
我编写的程序是小型的50-75 K行程序,主要使用Windows Forms和ASP.NET.这些程序是GUI密集型的,允许各种图形和图形处理的设计和布局.
我认为自己擅长OOP并练习平衡OOP和传统的程序方法来创建可维护的代码.
当我考虑设计模式时会出现问题.链接到线程有一个有趣的评论,可以使用设计模式,但不是故意.当我想故意使用设计模式(在我的程序设计中)时,感觉就像我超越了所需要的东西,我在" 建筑宇航员 " 的领域,所以我回到了我的传统方法和一切都顺利进行(即通常).
以MVC模式为例.如果我想使用Windows窗体或ASP.NET(Visual Studio 2005)实现这种模式,那么我必须编写一个"框架",编写框架似乎比应用程序的大小更值得.
也许我的应用程序太小,无法证明使用其中一些模式.也许我只是不了解模式或需要更多地研究它们.
有没有其他人体验过这种"建筑宇航员"的感觉？
你如何有意识地使用设计模式而不"过度"？
对于这种性质较小的应用程序,我通常更担心反模式关于设计模式.也就是说,它实际上是同一枚硬币的两面:我的设计模式的力量正在熟悉它们,以便认识到我所想到的任何解决方案的不太明显的利弊.我很少会不顾一切地完全实现完整的设计模式(除非我真的需要所有的功能); 然而,我经常通过识别我所处的路径并查看该解决方案的常见缺陷或缺点来为自己节省了很多未来的工作,然后我可以检查我未来的用途,看看它是否会成为对我而言是一个相关的问题.因此,设计模式的强大之处在于,您可以轻松预测当前解决方案对您潜在需求的未来后果,
"如何在没有"落水"的情况下故意使用设计模式？"
简单.
不要将MVC框架开发工作与模式混为一谈.
认识到你做过的每一件事都是在你之前完成的(由你或其他人完成).
当你重复一些事情 - 任何事情 - 你都在追随一种模式.
当你重复任何设计 - 无论多么小 - 你都遵循设计模式.
当你发现自己重复某些事情时,为你正在重复的事物指定一个名称.你看,你已经发现并命名了你的第一个设计模式.无论多小.
当您命名设计模式时,您可以考虑何时使用它,为什么使用它,它解决了什么以及使用它的后果是什么.无论多小.
涉及"重复设计元素"的每一条学习都是设计模式.无论多小.
每一个循环.每个if语句.每个对话框.每个文件都打开.这些都是设计模式.
大多数是语言的一部分,并具有明显的语言特定名称."IF","OPEN"等
一些设计模式比单个语句大,但小于整个MVC框架.那些是有趣的.学习那些.买书.阅读.MVC不会出现在大多数设计模式书中,因为 - 嗯 - 它太复杂,太难应用.
不要从MVC开始.从其他任何事情开始.
"建筑宇航员"是那些花费大量时间讨论设计的人,但实际上并没有让它发生任何变化.
我喜欢在"Refactor to Patterns"一书中提出的设计模式的方法.在这里,模式不是我们预先投资的东西,而是我们在降低代码复杂性之后才做的事情.因为这种方法需要开始使用功能代码,并且基于什么能够更容易地扩展代码以满足特定需求来选择重构,所以它的结果非常集中.
几乎任何适当的设计模式在应用时都应该简化.如果你让事情变得更复杂,你可能会针对你的具体问题走错方向.
MVC本身并不要求您编写任何框架.它只是意味着您将视图,控制器和模型代码分开.我使用MVC(或MVP)来处理简单的移动应用程序,因为我发现在编写测试时控制分离非常有利(更不用说在更改UI时).
我的猜测是你现在没有进行大量的单元测试或集成测试,因此这种划分对代码的质量和可读性有多大帮助并不明显.
我强烈建议您阅读Fowler对UI架构的报道.
京公网安备 11010802040832号 | 京ICP备19059560号-6 