【设计模式】全局观之为什么分三大类

曾经终败给现在 2022-07-11 15:28 144阅读 0赞

**引言**

距离设计模式敲完也有差不多一周多了，但是对于为什么要分为三大类还是不太理解，于是就出来了这篇博客

**全局观**

大家都知道设计模式可以根据目的分为三大类，分别是创建型模式、结构型模式、行为型模式

那么为什么这么分呢？下面说一下笔者的理解

**创建型模式：**主要用于处理对象的创建，实例化对象。但是，这可能会限制在系统内创建对象的类型或数目

**结构型模式：**处理类或对象间的组合。它将以不同的方式影响着程序，允许在补充写代码或自定义代码的情况下创建系统，而且具有重复使用性和应用性能

**行为型模式：**描述类或对象怎样进行交互和职责分配。影响系统的状态、行为流，简化、优化并且提高应用程序的可维护性

![SouthEast][]

**创建型模式**

1、简单工厂

**       ** 当我们的程序在实例化对象时，如果输入条件不一样，产生的对象也不一样，那么我们可以考虑使用简单工厂对不同的实例进行统一封装

**2、工厂方法**

它是针对简单工厂的改进版，添加了对ProductManager的抽象

**3、抽象工厂**

这个是最复杂的工厂模式，它用来生成一个产品线上的所有产品，我们假设一个产品线上包括多个产品，不同的产品线上的产品个数是一样的，这样我们需要一个针对产品线的抽象，并且很显然不同产品线上的产品是不可能混到一起的

**4、单例模式**

这是比较好理解的一个模式，从字面上说，就是程序在运行的过程中，希望在任意时刻，都只保留某个对象的唯一实例

**5、建造者模式**

对于一些复杂对象来说，它可以分成多个不同的部分，在实例化时，不同部分之间实例化的顺序，有时会有严格的限制，这时我们就可以使用建造者模式了

**6、原型模式**

我们在程序运行过程中，当需要有新的实例对象时，有时并不希望是从头创建一个对象，而是希望新的实例的状态和某个已存在的实例保持一致，这就是原型模式发挥作用的地方

**结构型模式**

**1、适配器模式**

当我们已经开发出一个模块，有一套清晰的接口，并且模块正在被某个功能使用（意味着模块接口改变的可能性不高），这是如果有另外一个功能也需要使用这个模块的功能，但是对应的是一套完全不同的接口，这时适配器就可以发挥作用了

**2、装饰模式**

假如我们已经开发了一套功能，然后根据需求，需要增加一些子功能，而且这些子功能是比较分散比较时可以增删的，这时如果直接修改接口，那么会造成接口功能复杂并且不稳定，针对这种情况，我们可以使用装饰模式

**3、桥接模式**

面向对象提倡的几个最佳实践包括：1）封装变化；2）面向接口编程；3）组合优于继承；4）类的职责尽量单一。桥接器完美的体现了这些，通过创建型模式，我们可以很好地达到面向接口编程的目标，也就是说我们在程序中各变量的声明类型是接口类型或者抽象类，而具体的实现类型则由不同的设计模式使用不同方式指定

**3、享元模式**

当我们系统中需要使用大量的小对象，但我们又不希望将所有的小对象都创建出来时，可以考虑使用享元模式，它会抽取小对象中的公共部分，将其封装为基类，然后针对不同条件创建小对象，同时在对象池中维护这些小对象，客户在需要使用小对象时，首先在对象池中查找，如果存在，直接返回。对于小对象中“个性”的部分，由调用小对象的客户端进行维护

**4、组合模式**

当我们的对象结构中存在“父子”关系时，可以考虑使用组合模式

**5、代理模式**

在编写程序时，有时我们希望使用某个对象或者模块的功能，但是因为种种原因，我们不能直接访问，这时就可以考虑使用代理模式

**6、装饰模式**

如果我们的程序需要深入调用某个模块的内部，但我们又不想和模块过紧耦合，这时可以考虑使用装饰模式，来对外部封装内部子系统的实现。简单的装饰可能和代理在某种程度上很相似。

**行为型模式**

**1、职责链模式**

如果完成一项业务，需要很多步相关操作，但是如果将这些操作完全封装到一个类或者方法里面，又违背了单一职责的原则。这时我们可以考虑使用职责链模式

**2、命令模式**

命令模式将发出命令和执行命令很好的区分开来，当我们执行某项业务时，客户端只需要构造一个请求，而不必关心业务实现的具体细节，即构造请求和业务实现是独立的

**3、解释器模式**

如果我们的系统中有些特定的问题反复出现，我们想要对这些问题进行抽象，那应该如何做？试想一下，当我们写完代码后，是如何进行编译的？无论对C\#还是Java，它们的编译器都会读取我们所写的每一行代码，并作出相应的解释。我们可以部分认为，编译器中存储了任何组合的语句，类似于C中的typedef。解释器做的就是类似的事情，它将具有通用性的问题进行抽取，对其解决方案进行综合处理

**4、迭代器模式**

访问者模式，针对的是存储在一起的不同类型的对象集合，如何进行遍历处理，那么针对存储在一起的相同类型的对象集合，我们应该如何进行遍历呢？迭代器模式可以帮我们做到

**5、中介者模式**

如果我们的系统中有多个对象，彼此之间都有联系，那这是一个对象之间耦合很高的系统，我们应该如何优化呢？我们可以建立一个知道所有对象的“对象”，在它内部维护其他对象之间的关联，这就是中介者模式

**6、备忘录模式**

当我们的系统中存在这样一种对象，它的属性很多，在某些情况下，它的一部分属性是需要进行备份和恢复的，那应该如何做？谈到备份和恢复，我们立刻想到可以使用原型模式，但那是针对所有属性的，备忘录模式可以很好地解决这里的问题

**7、观察者模式**

当我们的系统中，存在一个业务A，有其他多个业务都需要关注业务A，当它的状态发生变化时，其他业务都需要做出相应操作，这时我们可以使用观察者模式

**8、状态模式**

当我们的系统中的对象，需要根据传入的不同参数，进行不同的处理，而且传入参数的种类特别多，这时在方法内部会产生大量的if语句，来确定方法的执行分支。那么如何消除这些if语句呢？状态模式可以帮我们做到

**9、策略模式**

当我们的系统中，针对某项业务有多个算法时，如何对这些算法进行管理，我们可以考虑使用策略模式，它主要是针对一组可以提取相同接口的算法进行管理

**10、模板方法模式**

继承是面向对象的一大核心，而模板方法就是对继承的完美体现。对于某项业务来说，我们可以根据通用的流程，设计其方法骨架，针对不清晰或者不明确的地方，以抽象方法的方式来处理，然后根据不同的子业务，创建不同的子类，在子类中，实现那些抽象方法

**11、访问者模式**

当我们有一个对象集合，集合中的元素类型是不一样的，但类型是相对固定的，例如只有3种不同的类型，但是可能有30个元素。如果我们希望对集合中的所有元素进行某种操作，从接口的角度来看，由于类型不一致，我们很难通过一个统一的接口来遍历集合元素并对其进行操作。这时我们可以考虑使用访问者模式，它将获取某个元素和对元素进行操作进行了分离

**结语**

在学习一个东西之前，有一个全局观是很重要的，有助于你后面的学习。上文只是对设计模式有一个小小的介绍，具体详细的敬请期待后面的博客。关于设计模式，笔者只是个初学者，认识和理解比较浅显，有待深究。

**       本文只是对基础知识做一个小小的总结，不深究。如有不同，见解欢迎指正**

**       本文所有内容均为作者原创，如有转载，请注明出处**

[SouthEast]: /images/20220711/893b305971b0468f8b8188bec80ffe7d.png