设计模式-架构宇航员

Question

也许我的问题在本质上类似于这个问题：Do you use design patterns?

我写的程序是小的50-75K行程序，主要使用Windows Forms和ASP.NET。这些程序是图形用户界面密集型的，允许设计和布局各种图形和图形处理。

我认为自己擅长OOP，善于平衡OOP和传统的过程方法来创建可维护的代码。

当我考虑设计模式时，问题就出现了。链接到线程有一个有趣的注释，即可以使用设计模式，但不是故意的。当我想要有意地使用设计模式(在我的程序设计中)时，感觉就像是在超越所需要的东西，我处于"architecture astronaut“的领域，所以我退回到我的传统方法，一切都进行得很顺利(即正常)。

以MVC模式为例。如果我想要使用Windows Forms或ASP.NET (Visual Studio2005)来实现这个模式，那么我必须编写一个“框架”，并且编写框架似乎比应用程序的大小更麻烦。

也许我的应用程序太小，无法证明使用其中一些模式是合理的。也许我只是不太了解这些模式，或者需要更多地研究它们。

还有没有人体验过这种“建筑宇航员”的感觉？

如何才能有意识地使用设计模式，而不至于“走得太远”？

Answer 1

当涉及到这种性质的较小应用程序时，我通常更担心anti-patterns而不是设计模式。也就是说，这实际上是一枚硬币的两面:对我来说，设计模式的力量在于熟悉它们，以便认识到我正在考虑的任何解决方案的不太明显的优缺点。我很少真正完全实现一个完整的设计模式(除非我真的需要所有的功能)；然而，我经常通过认识到我所走的道路并查看该解决方案的常见陷阱或缺点来节省大量的未来重新工作，然后我可以检查我未来的使用情况，看看它是否与我相关。因此，设计模式的强大之处在于，您可以根据您的潜在需求轻松预测当前解决方案的未来结果，而不必担心您可能会遗漏一些不太明显的警告或您没有考虑到的特殊情况。

Answer 2

‘如何在不“过度”的情况下有意识地使用设计模式？’

很简单。

MVC不要把

• 框架的开发工作和模式混为一谈。

• 认识到你做的每一件事都是以前(由你或别人)做过的。

• 当你重复某事时--任何事--你是在遵循一个模式。

• 当你为任何事情重复设计时--不管有多小--你是在遵循一个设计模式。

• 当你注意到自己在重复某件事时，为你正在重复的事情指定一个名字。看，你已经发现并命名了你的第一个设计模式。无论多小。

• 当你命名了一个设计模式后，你就可以考虑什么时候使用它，为什么要使用它，它解决了什么问题，以及使用它的后果是什么。无论多小。

• 涉及到“重复设计元素”的每一项学习都是设计模式。无论多小。

每一次循环。每条if语句。每个对话框。所有打开的文件。这些都是设计模式。

大多数都是语言的一部分，并具有明显的特定于语言的名称。"IF“、"OPEN”等。

有些设计模式比单个语句更大，但比整个MVC框架更小。这些都是有趣的。学习这些。买一本书。读一读。MVC不会出现在大多数设计模式书籍中，因为--好吧--它太复杂太难应用了。

不要从MVC开始。从其他任何东西开始。

Answer 3

“建筑宇航员”是那些花费大量时间讨论设计，但实际上并没有实现任何设计的人。

我喜欢“重构到模式”这本书中介绍的设计模式的方法。在这里，模式不是我们前期投资的东西，而是我们只有在它挡路之后才能降低代码复杂性的东西。因为这种方法首先需要功能代码，并且根据什么可以更容易地扩展代码来满足特定需求来选择重构，所以它的结果非常集中。