设计模式 - 建筑宇航员 [关闭]

Posted 2023-02-24

【中文标题】设计模式 - 建筑宇航员 [关闭]

【英文标题】：Design Patterns - Architecture Astronaut [closed]

【发布时间】：2010-09-29 02:04:39

【问题描述】：

也许我的问题本质上与此类似：Do you use design patterns?

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

我认为自己擅长 OOP，并在平衡 OOP 和传统过程方法以创建可维护的代码方面进行了实践。

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

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

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

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

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

【问题讨论】：

好问题，但它可能属于programmers.stackexchange.com

或可能在softwareengineering.stackexchange.com

【参考方案1】：

当涉及到这种性质的小型应用程序时，我通常更担心anti-patterns 而不是设计模式。也就是说，这实际上是同一枚硬币的两个方面：对我来说，设计模式的力量在于熟悉它们，以便认识到我正在考虑的任何解决方案的不那么明显的利弊。我很少会不遗余力地完全实现一个完整的设计模式（除非我真的需要所有功能）；然而，我经常通过识别我所走的道路并查看该解决方案的常见缺陷或缺点，为自己节省了很多未来的返工，然后我可以检查我未来的用途，看看它是否会成为对我来说是否相关的问题。因此，设计模式的强大之处在于，您可以轻松预测当前解决方案针对您的潜在需求的未来后果，而不必担心您可能会错过一些您没有考虑过的不太明显的警告或特殊情况。

【讨论】：

+1 用于反模式，恕我直言，它们比设计模式更重要但文档记录更少。

【参考方案2】：

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

简单。

不要将 MVC 框架开发工作与模式混为一谈。

认识到您所做的每一件事都是以前做过的（由您或其他人完成）。

当你重复某件事——任何事情——时，你就是在遵循一种模式。

当您对任何事物重复设计时（无论多小），您都在遵循设计模式。

当您注意到自己在重复某件事时，请为您正在重复的那件事指定一个名称。看，您已经发现并命名了您的第一个设计模式。不管多小。

当您为设计模式命名后，您就可以考虑何时使用它、为什么使用它、它解决了什么问题以及使用它的后果是什么。不管多小。

每一项涉及“重复设计元素”的学习都是设计模式。不管多小。

每个循环。每个 if 语句。每个对话框。每个文件都打开。这些都是设计模式。

大多数是语言的一部分，并且具有明显的特定于语言的名称。 “如果”、“打开”等。

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

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

【讨论】：

+1 我很喜欢“不管多么小”，对模式的描述很好，但有一秒钟我以为我在读“霍顿听到谁”

好帖子，但我不得不吹毛求疵：设计模式的内涵是指软件架构部分的高级布局，而不是任何命名软件模式的通用词。例如，“冒泡排序”是可识别的软件模式，有名称，但不是设计模式。

设计模式怎么能不参考所有细节级别的所有模式？如果它们不是设计模式，我设计的其他模式是什么？冒泡排序是由较小的模式和较大模式的一部分组成的模式。

在较低级别，我相信您指的是“算法”，而不是模式。从某种意义上说，您所描述的是英语单词意义上的“模式”，您是对的-但我与朱丽叶一样，相信在提出问题的意义上，模式指的是更高层次的设计。一切都只是“在我看来”。

将“模式”限制在设计的“更高层次”是一种人为的区别，当你开始真正思考你在做什么、什么是可重复的以及什么是解决常见问题。

【参考方案3】：

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

我喜欢“重构到模式”一书中介绍的设计模式方法。在这里，模式不是我们预先投资的东西，而是我们为了降低代码复杂性而做的事情，只有在它妨碍了它之后。因为这种方法需要从功能代码开始，并根据更容易扩展代码以满足特定需求的方式来选择重构，所以它非常注重结果。

【参考方案4】：

几乎任何适当的设计模式在应用时都应该简化。如果您让事情变得更复杂，那么您可能会针对您的具体问题走错方向。

【参考方案5】：

MVC 本身并不要求您编写任何框架。它只是意味着您将视图、控制器和模型代码分开。我甚至将 MVC（或 MVP）用于简单的移动应用程序，因为我发现在编写测试时（更不用说在更改 UI 时）控制分离非常有利。

我的猜测是你现在没有做很多单元测试或集成测试，所以这个划分对你代码的质量和可读性有多大帮助并不是很明显。

我强烈建议您阅读Fowler's coverage of UI architectures。

【参考方案6】：

不要忘记沟通 - 众所周知的设计模式让您只需几句话就可以沟通复杂的事物。当你说“并且通知是使用观察者模式传递的”时，每个人都知道你的意思。

【参考方案7】：

很少有项目需要或受益于超架构。大多数以这种方式开始的项目永远不会完成。许多确实很难扩展或维护（尽管他们声称相反）。记住语言和技术的发展速度有多快。当你完成一个非常大的项目时，今天最新、最酷的东西可能已经过时了。模式很有趣，可以让您深入了解如何优雅地解决问题，但大多数时候，在现实世界中，没有优雅的解决方案。在我工作过的每个地方，都有一位超级明星宇航员，在编写我以后必须修复的垃圾代码时，他会吐出无尽的行话，给每个人留下深刻印象。最后的结果才是最重要的。您的公司需要一个有效的应用程序，而不是无休止的工作，即使他们自己没有意识到这一点。

【参考方案8】：

模式只是一般问题的抽象解决方案。如果一个人知道这些模式，那么他们更有可能更快地应用一个已知的解决方案，而不是坐在那里思考，“哎呀，我想知道如何使这项工作发挥作用。”

关于框架：如果您曾在一个多人的团队中工作过（这听起来不像是因为您的项目规模很小），那么框架可以帮助每个人以相同的方式做事，这对于团队的可维护性和快速让新人上手很重要。

【参考方案9】：

简单的问题通常需要简单的解决方案，尽管一些难题非常简单。另一方面，复杂的问题可以通过有组织的方式或肮脏的意大利面条代码来解决。许多人试图组织软件设计，一些“模式”出现并得到了名字。

我认为当您向他人传达您的设计意图时，模式是有用的词汇，但这并不是您将其强加到设计中的东西。当您根据需要使代码解耦时，您可以根据需要应用模式。例如，当您发现自己在制作非常复杂的构造函数时，可以使用构建器模式。

将数据层和 UI 层从您的业务逻辑中解耦出来，这与优秀的设计一样是您应该做的。同样，低耦合、DRY 和可维护的代码应该是目标，而不是模式。

【参考方案10】：

对我来说，这取决于：

应用程序的大小， 要使用的设计模式， 我必须在架构上预先投入的时间。

在小型应用程序中，我不太可能使用任何不能自然流动的设计模式，除非它们在扩展或维护应用程序的范围内具有很高的投资回报率。

【参考方案11】：

您在一个大公司为您设置模式的环境中工作，我认为这可以解释您的感受。你可能是对的。我们这些在开放环境中使用 FOSS 语言解决更广泛问题的人有无穷无尽的选择，阅读设计模式有助于我们做出有关架构的明智决策。通常这意味着选择正确的库。您正在为您工作的狭窄领域做出选择。

【参考方案12】：

恕我直言，需要：

充分了解不同设计的优缺点 您可以使用的模式 明确您的应用程序的设计用途和用途 确保该模式的优点被用于您的优势。

以MVC模式为例。如果 我想使用实现这个模式 WinForms 或 ASP.NET (VS 2005) 然后我 必须写一个“框架”和 编写框架似乎更多 麻烦比它的大小值得 应用程序。

您的网络应用程序是否需要有效的 SEO？为 ASP.NET 实现的 MVC 模式可以在这方面有所帮助。以 SO URL 为例。它们针对搜索引擎进行了如此出色的优化，主要是因为 ASP.NET 的 MVC 模式实现支持它并且已在 SO 设计/开发中得到有效使用。