Web开发中的设计模式

介绍

让我们开始吧！

最后的话

点击此处查看更新版本

介绍

前言

在深入研究本系列之前，您可能想知道我为什么要写这篇文章。

我叫曼努埃尔，我差不多是个意大利人，也差不多是个终生极客。虽然我从中世纪就开始从事网络开发<tables>，但直到三年前我才决定把软件开发作为全职工作。

你可以想象，我没有接受过计算机科学教育，因此我一直在努力通过尽可能多地学习“学术”主题来填补这一空白。

此外，我最近离开了祖国，因此我也需要一个好的理由来练习我的英语。

这正是本系列文章的由来。

这是关于什么的？

我想做的是根据我主要从四人帮学到的知识撰写有关设计模式的文章。

这篇文章与其他大量类似文章的不同之处在于，我将尝试坚持全栈 Web 开发，并提供极其实用的示例。由于其他语言也有很多关于此主题的资源，因此大多数示例将使用 JavaScript 或 Python 编写。

大致内容如下：如何在 React 组件、CQRS Node 应用程序中使用命令模式以及如何在 Electron 应用程序中实现撤消/重做历史记录。

不过，这第一篇文章是该系列的试播集。所以这里还没有模式 :(

让我们开始吧！

如果您想了解有关设计模式的更多信息，我可以推荐这个网站，当我需要重新认识这些概念时，我会去那里。

什么是设计模式？

尽管你们每个人都声称自己是世界上最好的厨师，因为他们有特殊的、独特的、独一无二的烹饪技巧（好吧，也许这对意大利的影响比其他地方更大……），但我们都同意，拥有一本祖母制作的食谱几乎可以让每个人都成为一名好厨师。

原因很简单：所有这些食谱都是由某个人创造的——最终犯下了大量错误——随着时间的推移，他不断修正、纠正和修改这些程序。运用这些精心打包的知识，可以让你避免许多常见的陷阱和错误的决定。这在以下情况下非常有用：你做出的选择看似无害，但当你把菜端给一个可能不像你想象中那么礼貌的人时，情况就大不相同了（意大利的食物真的很重要）。

同时，食谱可以作为模板，而不是刻在石头上的规则。有很多非常优秀的厨师会重新翻阅他们的家庭食谱，以此来创业，或者，总的来说，是为了实现他们可能与祖母时代不同的目的。

软件开发中，整个过程的运作方式基本相同。主要区别在于，软件开发项目通常持续几分钟以上，而且你不可能在项目结束时就刷牙
。除此之外，主要思路是相同的：有一个非常强大的起点来解决常见问题，当你达到一定的专业水平时，你可能会想要定制这些问题。

批评

至于所有那些好得令人难以置信的事情，这件事要么不那么好，要么不那么真实。

好消息是，这是真的 😀 但坏消息是，你的决策过程不能完全被古人的智慧所取代。

这是迄今为止软件开发中针对模式方法提出的最常见的论点：通过模式提供的解决方案往往不如针对特定问题那么有效。

对我来说，这算是一个弱点，因为你应该不断改进，或者至少根据你的需求调整其中一种解决方案。拥有经过时间考验的解决方案，能让你提前了解所选方案的大部分弱点，从而更好地理解如何解决后续问题。

反对设计模式的另一个常见论点是，一些经典的设计模式（即四人帮的设计模式）的存在仅仅是因为当时的软件开发状态，与我们今天所拥有的相比，这种状态有点“原始”。

好吧，我不能不同意这一点，但是（正如弗朗西斯所说）“知识就是力量”，我宁愿拥有一个我不使用的工具，也不愿缺少我需要的工具。

然而，这引出了我在这里要解决的最后一个批评。引入模式的风险之一是，你可能最终会在根本不需要它们的情况下使用它们。

我想这是我们无能为力的，而且这在任何以套路学习的东西中都是一个相当常见的问题（比如，当你开始学习音乐中的音阶时）。不幸的是，在这种情况下，经验是最好的老师，但意识到风险肯定会对你有所帮助。

分类

您现在可能已经明白了，“四人帮”在成立之初（顺便说一下，是 1995 年）确实很糟糕。

因此，如今我们仍然在某种程度上根据设计模式的分类对其进行分类。

只要我撰写有关该主题的文章，以下列表就会成为链接列表

创建模式

• 抽象工厂
• 建造者
• 工厂
• 原型
• 单例模式

结构模式

• 适配器
• 桥
• 合成的
• 装饰器
• 正面
• 蝇量级
• 代理人

行为模式

• 责任链
• 命令
• 解释器
• 迭代器
• 调解员
• 纪念
• 观察者
• 状态
• 战略
• 模板方法
• 游客

最后的话

这篇设计模式的介绍很简短，希望不会太枯燥。下一篇文章会更实用，少些冗长，可能还会有同样多的梗。
如果你对这个主题感兴趣，请告诉我，因为我真的很需要动力来继续写下去 :D