tp框架用到的设计模式,spring用到了哪些设计模式

在最近的一两个月里，我们正在研究各种模式，包括设计模式、架构模式、容器模式和其他特定领域的模式(例如并行计算模式)。

买了书，读了论文，读了代码，发现以前对模式的理解还不充分。也就是说，这篇文章用于记录缺少的东西，如模式语言、模式模式等。

PS :为了便于阅读，本文的书名都是用简写的。全名在最后的相关资料中。

为了避免Datum是最好的语言这一问题，模型的重新考虑首先要阐述对模型的看法。

模式是对于惯用方式的总结，不仅仅是编程，很多人都习惯使用各种各样的设计模式，但他不知道那是什么样的模式。这是一个概念表，用于快速沟通。

模式是解决方案，只有在符合锤子定律，遇到特定问题时才需要。

模式是适用于特定场景的

模式是知识体系的展现，掌握模式的多少，看更多的说明就有更多的知识，并不一定代表实际的代码水平和能力。

模式需要刻意练习学习模式是一个漫长的过程，可能会理解和解决，或者使用错误，请不要担心。

模式种类繁多，计算机行业普遍认可的是，模型起源于亚历山大的《建筑的永恒之道》。更早的时候，也有应对的总结，但这里是最系统化的技巧。

除了设计模式以外，我们这个行业还有很多模式。

针对容器设计模式。云本机APP的下一系列复杂划分方案，谷歌工程师发表并总结了相关论文。常见的有Sidecar、Adapter、Ambassador等。

架构模式。体系结构模型是一种通用的可重用解决方案，用于解决特定上下文中软件体系结构中的常见问题。此外，微服务器、事件驱动架构等常见的架构风格也大致分为架构模型。

……

所以，你会发现这些模式只是惯用法的总结。

当我们尝试寻找模式，发现我们要进入新的领域，进行相关领域的体系结构设计时，我们会不断地寻找各种类型的资料，然后贴在设计中。其实，我们在找这个领域的模特。有了这些模型，我们就可以按照猫虎的设计来设计系统，没什么大问题。

如果幸运的话，我们可以比这个领域的大多数人做得更好——。因为我们掌握了解决这种问题的模式。

在这个时候，我们已经有了一条非常有优势的道路，可以帮助我们进入更好的新领域。但是，作为新领域的初学者，往往不知道应该采用什么模式，也不知道模式之间有什么关系。

相关书籍：《设计模式》

模式分类：目录、集合、仓库在一个软件系统中，模式很少独立存在，往往多种模式相互组合，用于解决特定的问题。其中一种组织方式模式是模式集合然后根据需求分类。正如在《POSA 5》中介绍的那样，有几种方法。

即时(特定)组织。

按层次划分：按抽象、粒度、规模划分的层次划分。

分领域组织：电信、金融、电子商务等。

根据分区组织，它属于体系结构的哪个部分？例如，层次、层次、组件、程序包是分区的例子

根据意图组织：例如POSA、GoF 23种设计模式、DDD

……

接下来，我们来看几个分类示例。

设计模式的组织是《设计模式》本书，引入的概念是《设计模式空间》，这里分为三类：

创建型模式：单实例模式、抽象车间模式、建设者模式、车间模式、原型模式。

结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、元模式、代理模式。

行为型模式：模板方法模式、命令模式、迭代器模式、观察员模式、中间人模式、备忘录模式、解释模式、状态模式、策略模式、职责划分

其划分的两个标准分别为目的标准，用于完成什么工作；范围指南。指示指定的模式是用于类还是用于对象。

DDD的组织《领域驱动设计》这本书也在其中聚集了一个模式，这是这本书很难读的理由之一。另一个原因是，翻译这本书的人在统一语言

《领域驱动设计》这本书以各种形式组织了模式，以下四个部分是(PS )个人的临时总结) )。

运用领域模型——《模型知识提取的模型》

模型驱动设计的构造块——《模型设计的模型》

通过重构来加深理解——《模型优化的模型》

/p>

战略设计 —— 『模型边界划分的模式』

而这个顺序其实也是我们在实施 DDD 过程中的设计过程，而后再进行层次化的组织，如『战略设计』部分根据不同的意图，又分为不同的合集：

保持模型的完整性，如限界上下文、上下文地图等

精炼：核心域、通用域等

大型结构：演化秩序（Evolving Order）、系统隐喻等

所以从结构上来看，《领域驱动设计》是一本由小而大的书，阅读难度略大，需要一定的经验。

模式分类的意图

我们把『如何应用设计模式看作是一个问题域』，那么模式分类就是在这个问题域里的一种解决方案。

在计算机的不同的复杂领域里，如并行编程、架构设计等等，它们本身是包含了大量的模式。而有了对于这些模式的进一步分类，对于我们应用模式会有更大的帮助 —— 至少在应对同一个次级问题时，我们可以寻找可能的替代模式。

不过呢，多数时候，我们往往不知道的是：我们遇到的问题是什么？

角落里的模式语言

如《POSA 5》所定义的一样：模式语言与具体领域高度相关，并且能对这一类系统提供具体而周全的引导，具体包括以下几项：

要解决的主要问题有哪些？

这些问题应该以什么样的先后次序解决？

解决一个给定问题，有什么可用的替代解决方案？

怎样处理问题之间的依赖性？

在有“周边” 问题存在的情况下，怎样最有效地解决单个问题？

简单来说，模式语言针对于某个特定的问题（如并行编程）所抽象的模式，并包含了他们之间的关系等，能用于系统性地解决这一类问题。

书中还提到了 Gerard Meszaros 的观点“模式语言可以用来指导生手创建系统”。Aha，这不就是我们想要的东西吗？作为一个进入新领域的新人，我们需要这么一个模式语言。尽管模式语言可以帮助我们解决这一类的问题，但是它也意味着它自身需要：充分覆盖、进展可持续、紧密集成。依照这一系列的前提，它意味着设计这个模式语言的人应该是业内专家，并且模式本身应该是不断演进的。

因此，当我们把如何实施和使用模式看作是我们的问题时，那么模式语言解决这一类问题的模式。

分布式计算的模式语言

《POSA》系列大概是在中文世界里，我们所能找到的最好的资料。因此，这里再次以《POSA 4》作为例子，《POSA 4》全称是《面向模式的软件架构：分布式计算的模式语言》。

先来看图（图中的悦耳的猎豹表示的是问题域，连续表示的是他们的关系，每个问题域下包含了相关的模式）：

POSA Pattern Language

举例来说开头的『From Mud to Structure』（从混沌到结构）就是一个大的问题域，对应于这个问题域则包含了一系列的模式，如：MVC、分层、PAC、微内核等。同时，针对于这个问题题来说，如果我们还要数据库访问，那么我们从数据库访问中获得对应的模式，以此来完善我们的设计。

然后，在我们进入了具体的模式/问题域之后，它还详细介绍了如何实现对应的模式。如分层：

POSA Layer

有了这系列的配合，我们便可以完善整个系统的设计。

微服务的模式语言

接着，让我们来看看《微服务架构设计模式》中关于微服务的架构模式概述：

微服务模式语言

从上图中，我们可以看到由 dfddg Richardson 整理的这个微服务模式语言，对语言进行了多层的分类，并指明了它们之间的关系。颇为遗憾的是这个模式语言只包含了关系，缺少了一些相关关系的描述。

虽然如此，但是从总体上来说，它还是能在一定程度上帮助我们设计微服务。

相关书籍：《POSA 4》、《POSA 5》、《微服务架构设计模式》

模式的模式

从模式再模式归类，再到模式语言，我们已经有了整套的方案。最后，我们就剩下一些有意思的问题，诸如于如何发现新的模式？如何对现有的模式进行一些抽象。

对于『模式的模式』的理解，有助于我们更好地理解好设计模式。对于设计模式的理解之后，只需要理解其背后的模式，就不需要再去熟记每个设计模式。

所以，我们就来到了元素模式，依据的它也是来自于一本书《元素模式》。

元素模式：设计模式的模式

模式是来源于对惯用法的总结，而诸如于元素模式则是对于设计模式的提取，即模式中的模式。元素模式（Elemental Design Patterns）的核心要义是一组面向对象的基本概念。

对 OO 中的设计模式进行更细致的拆分，我们就能得到位于其背后的模式。作为其中的核心元素模式便是：创建对象、检索、继承和抽象接口。于是，如书上所说，结合这四个 EDP，我们可以创建对，并实施特定的保证，在运行时建立自此的关联，并从一种类型出发建立其他类型，以及创建出声明，并带有关于未来的、未定的类型的保证。

而我们在实施方法调用时，也被抽象了四个 EDP：递归、委托、重定向和集聚，以此构成了设计的砌块。

架构模式的模式

最后就回到了我想抽象的问题，那么架构模式其背后的模式又有什么呢？我试着进行了简单的拆解：

契约。输入与输出、API 等。

分割。隔离变化、明确职责等。

约束。功能需求和非功能需求、性能等。

封装。接口封装。

协作。协作风格等

……

当然了，我还需要他们进行重新命名，以构建在架构模式领域的统一语言。

其它

尽管，它有些复杂，但是依旧很有意思。