设计模式——深度解析：第 1 部分

引言

几天前，我的一位同事问了我一个问题：“如果一个应用程序是使用正确的设计模式创建的，这是否能确保应用程序没有错误/性能问题？”

这个问题的答案给了我一个想法，那就是写一系列文章来探讨什么是设计模式，设计模式能做什么/不能做什么，并希望能与读者们就你们的经验和见解展开有趣的讨论。

让我们以一个小小的步骤开始这段旅程，理解一些关于设计模式的定义，并从一个非常高的层面来看设计模式到底是什么。接下来的文章将专注于每个模式的细节，以及一些我们可以使用这些模式的场景。

什么是设计模式？

“在软件工程中，设计模式是软件设计中一个常见问题的通用可复用解决方案” - （维基百科，2008）

在我看来，设计模式是解决软件设计问题的“一种可能”的方案。我使用“一种可能”这个词，是因为即使一个设计模式“似乎”解决了你遇到的问题，你仍然需要分析这个问题，并确保所提供的解决方案/模式在你的开发工作范围内是有效的。

这种判断是通过成功使用该模式的经验，或在该过程中“碰壁”而获得的。经验丰富的架构师、设计师和开发人员会告诉你，即使你在之前的项目中多次使用过某个模式，你仍然需要评估在当前项目中是否使用该模式，因为需求/项目环境/时间点与上次使用时不同。

“模式涉及到对象的‘设计’和‘交互’，同时提供了一个‘交流平台’，用于讨论如何优雅地、可复用地解决编程中常见的挑战。” - （Data & Object Factory，2008）。

上面定义中的关键词是“交流平台”这个概念。设计模式不仅有助于对象之间的通信，还提供了一个与同行交流想法的平台。

例如，告诉别人你计划使用外观（Facade）模式而不是 MVC 会更容易，他们会立刻知道你计划做什么的“结构”。这样，你就可以直接开始讨论使用特定模式的优缺点，并专注于满足业务需求，而不是花时间解释你打算做什么。

注意：上面的陈述是假设“某人”也理解设计模式；否则，你总是可以指向本系列文章以获取更多信息 :P

什么不是设计模式？

这是我想到的一些条目，如果你有更多要添加的，我会继续更新这个列表。所以，开始吧：

• 设计模式不是架构模式 - 设计模式专门处理“软件设计”（对象创建、通信和行为）层面的问题，而架构模式处理“软件工程”（通信、操作、维护、环境、应用程序中的物理/逻辑层）层面的问题。
• 设计模式不是“你的”问题的解决方案 - 设计模式是“通用问题的通用解决方案”。你的应用程序不是一个通用的应用程序，所以你需要“定制”一个设计模式来解决你面临的具体问题。这种定制只在你应用程序的范围内，以解决那个特定问题。在不同的问题/项目中，你需要重新开始分析。
• 设计模式不是算法 - 设计模式不是实现，它们只是解决方案的“框架”，而算法是问题的实现（更新：感谢Neni-san在评论区的指正）问题的解决方案。所以，算法可以直接用于你的应用程序（例如，冒泡排序算法），而设计模式需要为你特定的应用程序量身定制。
• 设计模式不是一个锤子找钉子.
• 设计模式不是一个等待被提问的答案（这是我朋友兼同事Vasanth的一句名言）。

我为什么需要设计模式？

老实说，你可以不了解任何设计模式，继续你的编程生涯，并且做得很好。只要软件满足其业务目标，谁真的在乎它在幕后做什么呢？

那么，使用一个经过验证的开发范式而不是重复造轮子（除非轮子是方的，当然），会不会带来生产力上的好处？

你愿意通过使用标准的模板来避免那些难以修复的逻辑错误，而不是让它们出现在你的应用程序中吗？

你喜欢通过解释 MVC/MVP 模式的细微差别来显得很酷（或者是个书呆子，取决于听众），还是在一场争论中争论 MVC 到底是不是设计模式或者架构模式？

如果以上问题的答案都是响亮的是，那么很不幸，你确实需要了解什么是设计模式。

从好的方面来说——你现在有了一种新的方式来搞砸你的代码，而且人们可能会理解你搞砸了什么，并帮助你提供解决方案！

太棒了，什么时候开始？

如果你还没注意到，我们已经开始啦！

这是系列文章的第一篇，我希望能尽快发布下一篇。在那之前，你可以看看我之前的文章，它们与本文无关，但我希望它们足够有趣。

答案

关于我给同事回答的他在文章开头提出的问题，我意识到我的同事有两点是积极的

1. 他认识到所有软件项目本质上都存在 bug/性能问题——无论是已发现的还是未发现的。
2. 他好奇他新获得的知识是否能帮助他解决这些问题。

因为两个“正数”仍然是“正数”，所以我回答：“是的，没错！”