设计模式中篇

傷城~ 2021-10-23 14:26 262阅读 0赞

**9桥接模式**  
实现的系统可以多角度分类，每一个分类又有多种变化，就把变化分离出来让它们独立变化，减少耦合。  
适用场景：当需要大量的继承类处理的时候，造成有大量的继承类，可以适用桥接模式。桥接模式用聚合和合成代替继承。  
例如手机有多个品牌，每个品牌有各自多个功能，这会涉及大量的继承。  
**10模板模式**  
在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。  
介绍  
意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。  
主要解决：一些方法通用，却在每一个子类都重新写了这一方法。  
何时使用：有一些通用的方法。  
如何解决：将这些通用算法抽象出来。  
关键代码：在抽象类实现，其他步骤在子类实现。  
应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。  
优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。  
缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。  
使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。  
注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。  
**11外观模式**  
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。  
这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。  
例如股民买多支股票，多个股票相当于多个类，股民相当于客户端类，需要调用多个类，这个时候如果使用外观模式，外观类调用多个类，而客户端类只需要调用外观类。  
**12享元模式**  
享元模式（Flyweight Pattern）主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。  
享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。我们将通过创建 5 个对象来画出 20 个分布于不同位置的圆来演示这种模式。由于只有 5 种可用的颜色，所以 color 属性被用来检查现有的 Circle 对象。  
介绍  
意图：运用共享技术有效地支持大量细粒度的对象。  
主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。  
何时使用： 1、系统中有大量对象。 2、这些对象消耗大量内存。 3、这些对象的状态大部分可以外部化。 4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。 5、系统不依赖于这些对象身份，这些对象是不可分辨的。  
如何解决：用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。  
关键代码：用 HashMap 存储这些对象。  
应用实例： 1、JAVA 中的 String，如果有则返回，如果没有则创建一个字符串保存在字符串缓存池里面。 2、数据库的数据池。  
优点：大大减少对象的创建，降低系统的内存，使效率提高。  
缺点：提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。  
使用场景： 1、系统有大量相似对象。 2、需要缓冲池的场景。  
注意事项： 1、注意划分外部状态和内部状态，否则可能会引起线程安全问题。 2、这些类必须有一个工厂对象加以控制  
**13代理模式**  
在代理模式（Proxy Pattern）中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。  
在代理模式中，我们创建具有现有对象的对象，以便向外界提供功能接口。  
应用实例：spring aop 和spring事务。  
**14责任链模式**  
顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。  
在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。  
举例：请假审批 通常是 组长，经理，董事长，他们根据不同的请假天数，走到不同的职位审批。这样请假者类就会有大量的if判断，相同的方法是三个职位都是同意或者到下一级。这样把这个方法抽象为一个父类，子类去实现，并且每个子类的构造方法传入下一个子类，这样就是职责链模式。  
**15观察者模式**  
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。  
介绍  
意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。  
主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。  
何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。  
如何解决：使用面向对象技术，可以将这种依赖关系弱化。  
关键代码：在抽象类里有一个 ArrayList 存放观察者们。  
应用实例： 1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。  
优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。  
缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。  
**16状态模式**  
在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。  
在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。

介绍  
意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。  
主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。  
何时使用：代码中包含大量与对象状态有关的条件语句。  
如何解决：将各种具体的状态类抽象出来。  
关键代码：通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。**状态模式和命令模式一样，也可以用于消除 if…else 等条件选择语句。**  
**17命令模式**  
命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。  
介绍  
意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。  
主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。  
何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。  
如何解决：通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。  
关键代码：定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口