设计模式——开发常用的设计模式梳理

. 基础学习：UML四种关系

耦合度大小关系

泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

依赖(Dependency)

好好学java

一个人(Person)可以买车(car)和房子(House)，那么就可以称：Person类依赖于Car类和House类
   这里注意与下面的关联关系区分：Person类里并没有使用Car和House类型的属性，Car和House的实例是以参量的方式传入到buy()方法中。
   依赖关系在Java语言中体现为局域变量、方法的形参，或者对静态方法的调用。

关联(Association）

好好学java

它使一个类知道另一个类的属性和方法。
   关联可以是双向的，也可以是单向的。
   在Java语言中，关联关系一般使用成员变量来实现。

聚合(Aggregation)

好好学java

聚合是关联关系的一种，是强的关联关系。
   聚合是整体和个体之间的关系，但个体可以脱离整体而存在。
   例如，汽车类与引擎类、轮胎类，以及其它的零件类之间的关系便整体和个体的关系。
   与关联关系一样，聚合关系也是通过成员变量实现的。但是关联关系所涉及的两个类是处在同一层次上的，而在聚合关系中，两个类是处在不平等层次上的，一个代表整体，另一个代表部分。

组合(Composition)

好好学java

组合是关联关系的一种，是比聚合关系强的关系，也以成员变量的形式出现。
   在某一个时刻，部分对象只能和一个整体对象发生组合关系，由后者排他地负责生命周期。
   部分和整体的生命周期一样。
   整体可以将部分传递给另一个对象，这时候该部分的生命周期由新整体控制，然后旧整体可以死亡。

. 策略模式

什么是策略模式

一个类中的一些行为，可能会随着系统的迭代而发生变化。为了使得该类满足开放-封闭原则（即：具备可扩展性 或 弹性），我们需要将这些未来会发生动态变化的行为从该类中剥离出来，并通过预测未来业务发展的方式，为这些行为抽象出共有的特征，封装在抽象类或接口中，并通过它们的实现类提供具体的行为。原本类中需要持有该抽象类/接口的引用。在使用时，将某一个具体的实现类对象注入给该类所持有的接口/抽象类的引用。

类图描述

好好学java

如果类A中有两个行为X和Y会随着业务的发展而变化，那么，我们需要将这两个行为从类A中剥离出来，并形成各自的继承体系(策略体系)。每个继承体系(策略体系)的顶层父类/接口中定义共有行为的抽象函数，每个子类/实现类中定义该策略体系具体的实现。

其中，每一个被抽象出来的继承体系被称为一个策略体系，每个具体的实现类被称为策略。

此时，策略体系已经构建完成，接下来需要改造类A。
在类A中增加所需策略体系的顶层父类/接口，并向外暴露一个共有的函数action给调用者使用。

在Spring项目中，策略类和类A之间的依赖关系可以通过依赖注入来完成。

到此为止，策略模式已经构建完成，下面我们来看优缺点分析。

策略模式的优点

1. 满足开放封闭原则

如果类A需要更换一种策略的时候，只需修改Spring的XML配置文件即可，其余所有的代码均不需要修改。

比如，将类A的策略X_1更换成X_2的方法如下：

<bean id="a" class="类A">    <!-- 将原本策略实现类X_1修改为策略实现类X_2即可 -->    <property name="策略接口X" class="策略实现类X_2" /></bean>

此外，如果需要新增一种策略，只需要为策略接口X添加一个新的实现类即可，并覆盖其中的commonAction函数。然后按照上面的方式修改XML文件即可。

在这个过程中，在保持原有Java代码不发生变化的前提下，扩展性了新的功能，从而满足开放封闭原则。

2. 可方便地创建具有不同策略的对象

如果我们需要根据不同的策略创建多种类A的对象，那么使用策略模式就能很容易地实现这一点。

比如，我们要创建三个A类的对象，a、b、c。其中，a使用策略X_1和Y_1，b使用策略X_2和Y_2，c使用策略X_3和Y_3。
要创建这三个对象，我们只需在XML中作如下配置即可：

<bean id="a" class="类A">    <property name="策略接口X" class="策略实现类X_1" />    <property name="策略接口Y" class="策略实现类Y_1" /></bean><bean id="b" class="类A">    <property name="策略接口X" class="策略实现类X_2" />    <property name="策略接口Y" class="策略实现类Y_2" /></bean><bean id="c" class="类A">    <property name="策略接口X" class="策略实现类X_3" />    <property name="策略接口Y" class="策略实现类Y_3" /></bean>

答疑

问：如何实现部分继承？也就是类Son1只继承Father的一部分功能，Son2继承Father的另一部分功能。

这是设计上的缺陷，当出现这种情况时，应当将父类再次拆分成2个子类，保证任何一个父类的行为和特征均是该继承体系中共有的！

好好学java

问：随着需求的变化，父类中需要增加共有行为时怎么办？这就破坏了“开放封闭原则”。

这并未破坏“开放封闭原则”！在系统迭代更新的过程中，修改原有的代码是在所难免的，这并不违背“开放封闭原则”。
“开放封闭原则”要求我们：当系统在迭代过程中，第一次出现某一类型的需求时，是允许修改的；在此时，应该对系统进行修改，并进行合理地设计，以保证对该类型需求的再次修改具备可扩展性。当再一次出现该类型的需求时，就不应该修改原有代码，只允许通过扩展来满足需求。

. 观察者模式

观察者模式是什么

如果出现如下场景需求时，就需要使用观察者模式。

如果存在一系列类，他们都需要向指定类获取指定的数据，当获取到数据后需要触发相应的业务逻辑。这种场景就可以用观察者模式来实现。

在观察者模式中，存在两种角色，分别是：观察者和被观察者。被观察者即为数据提供者。他们呈多对一的关系。

类图描述

好好学java

  • 被观察者是数据提供方，观察者是数据获取方

  • 一个普通的类，如果要成为观察者，获取指定的数据，一共需要如下几步：
    • 首先，需要实现Observer接口，并实现update函数；
    • 然后，在该函数中定义获取数据后的业务逻辑；
      update(Observable, Object)一共有两个参数：
        Observable：被观察者对象（数据提供方）
        Object：数据本身
    • 最后，通过调用 被观察者 的addObservable()或者通过Spring的XML配置文件完成观察者向被观察者的注入。此时，该观察者对象就会被添加进 被观察者 的List中。
  • 调用者才是真正的数据提供方。当调用者需要广播最新数据时，只需调用 被观察者 的notidyObservers()函数，该函数会遍历List集合，并依次调用每个Observer的update函数，从而完成数据的发送，并触发每个Observer收到数据后的业务逻辑。

两种注册观察者的方式

将Observer注册进Observable中有如下两种方式：

1. 运行前，通过Spring XML

在系统运行前，如果观察者数量可以确定，并在运行过程中不会发生变化，那么就可以在XML中完成List对象的注入，这种方式代码将会比较简洁。

1、配置好所有 观察者 bean

<!-- 创建observerA --><bean name="observerA" class="ObservserA"></bean><!-- 创建observerB--><bean name="observerB" class="ObservserB"></bean>

2、 配置好 被观察者 bean，并将所有观察者bean注入给被观察者bean

<!-- 创建observable --><bean name="observable" class="Observable">    <property name="observerList">        <list>            <ref bean="observerA" />            <ref bean="observerB" />        </list>    </property></bean>

2. 运行中，通过addObserver()函数

在Spring初始化的时候，通过addObserver()函数将所有Observer对象注入Observable的observerList中。

@Componentpublic class InitConfiguration implements ApplicationListener<ContextRefreshedEvent>{    @Override    public void onApplicationEvent(ContextRefreshedEvent arg0) {        if(event.getApplicationContext().getParent() == null){            Observable observable = (Observable)event.getApplicationContext().getBean("observable");            ObserverA observerA = (ObserverA)event.getApplicationContext().getBean("observerA");            ObserverB observerB = (ObserverB)event.getApplicationContext().getBean("observerB");            observable.setObserverList(Arrays.asList(observerA, observerB));        }      }}

建议使用第一种方式初始化所有的观察者，此外，被观察者仍然需要提供addObserver()函数供系统在运行期间动态地添加、删除观察者对象。

JDK提供的观察者模式工具包

JDK已经提供了观察者模式的工具包，包括Observable类和Observer接口。若要实现观察者模式，直接使用这两个工具包即可。

. 装饰模式

何时使用

  • 需要增强一个对象中某些函数的功能。
  • 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
  • 需要增加 由一些基本功能排列组合 而产生的大量功能，从而使继承体系大爆炸。

类图描述

好好学java
在装饰模式中的各个角色有：

  • 抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。

  • 具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
  • 装饰（Decorator）角色：持有一个构件（Component）对象的实例，并定义一个与抽象构件接口一致的接口。
  • 具体装饰（Concrete Decorator）角色：负责给构件对象”贴上”附加的责任。

Decorator中包含Component的成员变量，每个Concrete Decorator实现类均需要实现operation()函数，该函数大致过程如下：

class ConcreteDecorator {    private Component component;    返回类型 operation(){        // 执行上一层的operation()，并获取返回结果        返回结果 = component.operation();        // 拿到返回结果后，再做额外的处理        处理返回结果        return 返回结果;    }}

使用装饰类的过程如下：

// 准备好所有装饰类DecoratorA decoratorA = new DecoratorA();DecoratorB decoratorB = new DecoratorB();DecoratorC decoratorC = new DecoratorC();// 准备好 被装饰的类Component component = new Component();// 组装装饰类decoratorC.setComponent(decoratorB);decoratorB.setComponent(decoratorA);decoratorA.setComponent(component);// 执行decoratorC.operation();

执行过程如下：

好好学java

优点

1、Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。继承通过覆盖的方式重写需要扩展的函数，当然也可以通过super.xxx()获取原本的功能，然后在该功能基础上扩展新功能，但它只能增加某一项功能；如果要通过继承实现增加多种功能，那么需要多层继承多个类来实现；而Decorator模式可以在原有功能的基础上通过组合来增加新功能，这些新功能已经被封装成一个个独立的装饰类，在运行期间通过搭积木的方式选择装饰类拼凑即可。

2、通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

缺点

1、这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。
2、装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。

3、装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

设计原则

  • 多用组合，少用继承。
    利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。

. 单例模式

Java中单例(Singleton)模式是一种广泛使用的设计模式。单例模式的主要作用是保证在Java程序中，某个类只有一个实例存在。一些管理器和控制器常被设计成单例模式。

单例模式有很多好处，它能够避免实例对象的重复创建，不仅可以减少每次创建对象的时间开销，还可以节约内存空间；能够避免由于操作多个实例导致的逻辑错误。如果一个对象有可能贯穿整个应用程序，而且起到了全局统一管理控制的作用，那么单例模式也许是一个值得考虑的选择。

单例模式有很多种写法，大部分写法都或多或少有一些不足。下面将分别对这几种写法进行介绍。

. 饿汉模式

public class Singleton{      private static Singleton instance = new Singleton();      private Singleton(){}      public static Singleton newInstance(){          return instance;      }  }  
  • 类的构造函数定义为private，保证其他类不能实例化此类；
  • 然后提供了一个静态实例并返回给调用者；
  • 饿汉模式在类加载的时候就对实例进行创建，实例在整个程序周期都存在
  • 优点：只在类加载的时候创建一次实例，不会存在多个线程创建多个实例的情况，避免了多线程同步的问题。
  • 缺点：即使这个单例没有用到也会被创建，而且在类加载之后就被创建，内存就被浪费了。
  • 适用场景：这种实现方式适合单例占用内存比较小，在初始化时就会被用到的情况。但是，如果单例占用的内存比较大，或单例只是在某个特定场景下才会用到，使用饿汉模式就不合适了，这时候就需要用到懒汉模式进行延迟加载。

. 懒汉模式(存在线程安全性问题)

public class Singleton{      private static Singleton instance = null;      private Singleton(){}      public static Singleton newInstance(){          if(null == instance){              instance = new Singleton();          }          return instance;      }  }  
  • 懒汉模式中单例是在需要的时候才去创建的，如果单例已经创建，再次调用获取接口将不会重新创建新的对象，而是直接返回之前创建的对象。
  • 如果某个单例使用的次数少，并且创建单例消耗的资源较多，那么就需要实现单例的按需创建，这个时候使用懒汉模式就是一个不错的选择。
  • 但是这里的懒汉模式并没有考虑线程安全问题，在多个线程可能会并发调用它的getInstance()方法，导致创建多个实例，因此需要加锁解决线程同步问题，实现如下。

. 懒汉模式(线程安全，但效率低)

public class Singleton{      private static Singleton instance = null;      private Singleton(){}      public static synchronized Singleton newInstance(){          if(null == instance){              instance = new Singleton();          }          return instance;      }  }

加锁的懒汉模式看起来即解决了线程并发问题，又实现了延迟加载，然而它存在着性能问题，依然不够完美。synchronized修饰的同步方法比一般方法要慢很多，如果多次调用getInstance()，累积的性能损耗就比较大了。

. 懒汉模式(线程安全，效率高)

public class Singleton {      private static Singleton instance = null;      private Singleton(){}      public static Singleton getInstance() {          if (instance == null) {             synchronized (Singleton.class) {                  if (instance == null) {                     instance = new Singleton();                  }              }          }          return instance;      }  }

这种方式比上一种方式只多加了一行代码，那就是在synchronized之上又加了一层判断if (instance == null)。这样当单例创建完毕后，不用每次都进入同步代码块，从而能提升效率。当然，除了初始化单例对象的线程ThreadA外，可能还存在少数线程，在ThreadA创建完单例后，刚释放锁的时候进入同步代码块，但此时有第二道if (instance == null)判断，因此也就避免了创建多个对象。而且进入同步代码块的线程相对较少。

. 静态内部类(懒汉+无锁)

public class Singleton{      private static class SingletonHolder{          public static Singleton instance = new Singleton();      }      private Singleton(){}      public static Singleton newInstance(){          return SingletonHolder.instance;      }  }  

这种方式同样利用了类加载机制来保证只创建一个instance实例。它与饿汉模式一样，也是利用了类加载机制，因此不存在多线程并发的问题。不一样的是，它是在内部类里面去创建对象实例。这样的话，只要应用中不使用内部类，JVM就不会去加载这个单例类，也就不会创建单例对象，从而实现懒汉式的延迟加载。也就是说这种方式可以同时保证延迟加载和线程安全。

. 枚举

public enum Singleton{      instance;      public void whateverMethod(){}      }

上面提到的四种实现单例的方式都有共同的缺点：

1、需要额外的工作来实现序列化，否则每次反序列化一个序列化的对象时都会创建一个新的实例。
2、可以使用反射强行调用私有构造器（如果要避免这种情况，可以修改构造器，让它在创建第二个实例的时候抛异常）。

而枚举类很好的解决了这两个问题，使用枚举除了线程安全和防止反射调用构造器之外，还提供了自动序列化机制，防止反序列化的时候创建新的对象。因此，《Effective Java》作者推荐使用的方法。不过，在实际工作中，很少看见有人这么写。

. 模板方法模式

定义

在父类中定义算法的流程，而算法的某些无法确定的细节，通过抽象函数的形式，在子类中去实现。

也可以理解为，一套算法的某些步骤可能随着业务的发展而改变，那么我们可以将确定的步骤在父类中实现，而可变的步骤作为抽象函数让其在子类中实现。

  • 在模板方法模式中，父类是一个抽象类，算法的每一步都被封装成一个函数，templateMethod函数将所有算法步骤串联起来。
  • 对于不变的步骤，用private修饰，防止子类重写；
  • 对于可变的步骤，用abstract protected修饰，必须要求子类重写；
  • 子类重写完所有抽象函数后，调用templateMethod即可执行算法。

. 外观模式

外观模式这种思想在项目中普遍存在，也极其容易理解，大家一定用过，只是没有上升到理论的层面。这里对这种思想进行介绍。

外观模式他屏蔽了系统功能实现的复杂性，向客户端提供一套极其简单的接口。客户端只需要知道接口提供什么功能，如何调用就行了，不需要管这些接口背后是如何实现的。从而使得客户端和系统之间的耦合度大大降低，客户端只需跟一套简单的Facade接口打交道即可。

. 适配器模式

定义

作为一个基金交易平台，需要提供一套接口规范，供各个基金公司接入。然而，各个基金公司的接口各不相同，没有办法直接和平台接口对接。此时，各个基金公司需要自行实现一个适配器，适配器完成不同接口的转换工作，使得基金公司的接口和平台提供的接口对接上。

. 三种适配器

适配器模式有三种实现方式，下面都以基金交易平台的例子来解释。

  • 基金公司的交易接口：
/** * 基金公司的交易接口 */class FundCompanyTrade{    /**     * 买入函数     */    public void mairu() {        // ……    }    /**     * 卖出函数     */    public void maichu() {        // ……    }}
  • 基金交易平台的交易接口
/** * 基金交易平台的交易接口 */interface FundPlatformTrade {    // 买入接口    void buy();    // 卖出接口    void sell();}
  • 基金交易平台均通过如下代码调用各个基金公司的交易接口：
class Client {    @Autowired    private FundPlatformTrade fundPlatformTrade;    /**     * 买入基金     */     public void buy() {        fundPlatformTrade.buy();     }    /**     * 卖出基金     */     public void sell() {        fundPlatformTrade.sell();     }}

方式1：类适配器

通过继承来实现接口的转换。

  • 基金交易适配器：
class Adapter extends FundCompanyTrade implements FundPlatformTrade {    void buy() {        mairu();    }    void sell(){        maichu();    }}

适配器Adapter继承了FundCompanyTrade，因此拥有了FundCompanyTrade买入和卖出的能力；适配器Adapter又实现了FundPlatformTrade，因此需要实现其中的买入和卖出接口，这个过程便完成了基金公司交易接口向基金平台交易接口的转换。

使用时，只需将Adapter通过Spring注入给Client类的fundPlatformTrade成员变量即可：

<!-- 声明Adapter对象 --><bean name="adapter" class="Adapter"></bean><!-- 将adapter注入给Client --><bean class="Client">    <property name="fundPlatformTrade" ref="adapter" /></bean>

方式2：对象适配器

通过组合来实现接口的转换。

  • 基金交易适配器：
class Adapter implements FundPlatformTrade {    @Autowired    private FundCompanyTrade fundCompanyTrade;    void buy() {        fundCompanyTrade.mairu();    }    void sell(){        fundCompanyTrade.maichu();    }}

这种方式中，适配器Adapter并未继承FundCompanyTrade，而是将该对象作为成员变量注入进来，一样可以达到同样的效果。

方式3：接口适配器

当存在这样一个接口，其中定义了N多的方法，而我们现在却只想使用其中的一个到几个方法，如果我们直接实现接口，那么我们要对所有的方法进行实现，哪怕我们仅仅是对不需要的方法进行置空（只写一对大括号，不做具体方法实现）也会导致这个类变得臃肿，调用也不方便，这时我们可以使用一个抽象类作为中间件，即适配器，用这个抽象类实现接口，而在抽象类中所有的方法都进行置空，那么我们在创建抽象类的继承类，而且重写我们需要使用的那几个方法即可。

  • 目标接口：A
public interface A {    void a();    void b();    void c();    void d();    void e();    void f();}
  • 适配器：Adapter
    实现所有函数，将所有函数先置空。
public abstract class Adapter implements A {    public void a(){        throw new UnsupportedOperationException("对象不支持这个功能");    }    public void b(){        throw new UnsupportedOperationException("对象不支持这个功能");    }    public void c(){        throw new UnsupportedOperationException("对象不支持这个功能");    }    public void d(){        throw new UnsupportedOperationException("对象不支持这个功能");    }    public void e(){        throw new UnsupportedOperationException("对象不支持这个功能");    }    public void f(){        throw new UnsupportedOperationException("对象不支持这个功能");    }}
  • 实现类：Ashili
    继承适配器类，选择性地重写相应函数。
public class Ashili extends Adapter {    public void a(){        System.out.println("实现A方法被调用");    }    public void d(){        System.out.println("实现d方法被调用");    }}

. 迭代器模式

定义

迭代器模式用于在无需了解容器内部细节的情况下，实现容器的迭代。

容器用于存储数据，而容器的存储结构种类繁多。在不使用适配器模式的情况下，如果要迭代容器中的元素，就需要充分理解容器的存储结构。存储结构不同，导致了不同容器的迭代方式都不一样。这无疑增加了我们使用容器的成本。

而迭代器模式提出了一种迭代容器元素的新思路，迭代器规定了一组迭代容器的接口，作为容器使用者，只需会用这套迭代器即可。容器本身需要实现这套迭代器接口，并实现其中的迭代函数。也就是容器提供方在提供容器的同时，还需要提供迭代器的实现。因为容器本身是了解自己的存储结构的，由它来实现迭代函数非常合适。而我们作为容器的使用者，只需知道怎么用迭代器即可，无需了解容器内部的存储结构。

类图描述

好好学java
在迭代器模式中，一共有两种角色：迭代器 和 容器

  • 迭代器 Iterator：封装了迭代容器的接口

  • 容器 Container：存储元素的东西
    • 容器若要具备迭代的能力，就必须拥有getIterator()函数，该函数将会返回一个迭代器对象
    • 每个容器都有属于自己的迭代器内部类，该内部类实现了Iterator接口，并实现了其中用于迭代的两个函数hasNext()和next()
    • boolean hasNext()：用于判断当前容器是否还有尚未迭代完的元素
    • Object next()：用于获取下一个元素

代码实现

  • 迭代器接口：
public interface Iterator {   public boolean hasNext();   public Object next();}
  • 容器接口：
public interface Iterator {   public boolean hasNext();   public Object next();}
  • 具体的容器（必须实现Container接口）：
public class NameRepository implements Container {   public String names[] = {"Robert" , "John" ,"Julie" , "Lora"};   @Override   public Iterator getIterator() {      return new NameIterator();   }   private class NameIterator implements Iterator {      int index;      @Override      public boolean hasNext() {         if(index < names.length){            return true;         }         return false;      }      @Override      public Object next() {         if(this.hasNext()){            return names[index++];         }         return null;      }           }}
  • 具体的容器实现了Container接口，并实现了其中的getIterator()函数，该函数用于返回该容器的迭代器对象。
  • 容器内部需要实现自己的迭代器内部类，该内部类实现Iterator接口，并实现了其中的hasNext()和next()函数。

当容器和容器的迭代器创建完毕后，接下来就轮到用户使用了，使用就非常简单了：

public class IteratorPatternDemo {   public static void main(String[] args) {      NameRepository namesRepository = new NameRepository();      for(Iterator iter = namesRepository.getIterator(); iter.hasNext();){         String name = (String)iter.next();         System.out.println("Name : " + name);      }        }}
  • 对于使用者而言，只要知道Iterator接口，就能够迭代所有不同种类的容器了。

. 组合模式

定义

组合模式定义了树形结构的物理存储方式。

现实世界中树形结构的东西，在代码实现中，都可以用组合模式来表示。

比如：多级菜单、公司的组织结构等等。

下面就以多级菜单为例，介绍组合模式。

例子

假设我们要实现一个多级菜单，并实现多级菜单的增删改查操作。菜单如下：

一级菜单A    二级菜单A_1        三级菜单A_1_1        三级菜单A_1_2        三级菜单A_1_3    二级菜单A_2一级菜单B    二级菜单B_1    二级菜单B_2    二级菜单B_3    二级菜单B_4        三级菜单B_4_1        三级菜单B_4_2        三级菜单B_4_3一级菜单C    二级菜单C_1    二级菜单C_2    二级菜单C_3

菜单的特点如下：

  • 深度不限，可以有无限级菜单
  • 每层菜单数量不限

类图描述

  • Item表示树中的节点；
  • Item中包含两个成员变量：
    • parent：指向当前节点的父节点
    • childList：当前节点的子节点列表
  • 这种Item中又包含Item的关系就构成了组合模式。

注意：循环引用

在构建树的过程中，可能会出现循环引用，从而在遍历树的时候可能就会出现死循环。因此，我们需要在添加节点的时候避免循环引用的出现。

我们可以在Item中再添加一个List成员变量，用于记录根节点到当前节点的路径。该路径可以用每个节点的ID表示。一旦新加入的节点ID已经出现在当前路径中的时候，就说明出现了循环引用，此时应该给出提示。

. 状态模式

使用场景

如果一个函数中出现大量的、复杂的if-else判断，这时候就要考虑使用状态模式了。

因为大量的if-else中往往包含了大量的业务逻辑，很有可能会随着业务的发展而变化。如果将这些业务逻辑都写死在一个类中，那么当业务逻辑发生变化的时候就需要修改这个类，从而违反了开放封闭原则。而状态模式就能很好地解决这一问题。

状态模式将每一个判断分支都封装成一个独立的类，每一个判断分支成为一种“状态”，因此每一个独立的类就成为一个“状态类”。并且由一个全局状态管理者Context来维护当前的状态。

类图描述

  • 在状态模式中，每一个判断分支被成为一种状态，每一种状态，都会被封装成一个单独的状态类；
  • 所有的状态类都有一个共同的接口——State
  • State接口中有一个doAction函数，每个状态类的状态处理逻辑均在该函数中完成；必须将Context对象作为doAction函数的参数传入。该函数的结构如下：
class StateA implements State{    public void doAction(Context context){        if (满足条件) {            // 执行相应的业务逻辑        }        else {            // 设置下一跳状态            context.setState(new StateB());            // 执行下一跳状态            context.doCurState();        }    }}
  • 每个状态类的doAction函数中都有且仅有一对if-else，if中填写满足条件时的业务逻辑，而else中填写不满足条件时的业务逻辑。
  • else中的代码都一样，有且仅有这两步：
    首先将context的state设为下一个状态对象；
    然后调用context的doCurState()执行；
  • Context类其实就是原本包含那个巨大、复杂的if-else的类。该类中持有了State对象，表示当前要执行的状态对象。
  • Context类必须要有一个doCurState函数，该函数的代码都一样：state.doAction()
  • 开启状态判断过程的代码如下：
// 准备好第一个状态StateA stateA = new StateA();// 设置第一个状态context.setState(stateA);// 开始执行context.doCurState();

优点

状态模式将原本在一个类中的庞大的if-else拆分成一个个独立的状态类。原本这个包含庞大if-else的类成为Context，包含了当前的状态。Context只需要知道起始状态类即可，不需要知道其他状态类的存在。也就是Context只与第一个状态类发生耦合。而每一个状态类只和下一个状态类发生耦合，从而形成一条状态判断链。状态类之间的耦合通过Spring XML文件配置。这样，当判断逻辑发生变化的时候，只需要新增状态类，并通过修改XML的方式将新的状态类插入到判断逻辑中。从而满足了开放封闭原则。
代理模式

. 代理模式

好好学java

代理模式是在不改变目标类和使用者的前提下，扩展该类的功能。

代理模式中存在『目标对象』和『代理对象』，它们必须实现相同的接口。用户直接使用代理对象，而代理对象会将用户的请求交给目标对象处理。代理对象可以对用户的请求增加额外的处理。

Java动态代理的使用

  • 首先你得拥有一个目标对象，该对象必须要实现一个接口：
public interface Subject   {     public void doSomething();   }  
public class RealSubject implements Subject   {     public void doSomething()     {       System.out.println( "call doSomething()" );     }   }  
  • 其次，为目标对象增加额外的逻辑：
    • 自定义一个类，并实现InvocationHandler接口；
    • 实现invoke函数，并将需要增加的逻辑写在该函数中；
public class ProxyHandler implements InvocationHandler   {     private Object proxied;     public ProxyHandler( Object proxied )     {       this.proxied = proxied;     }     public Object invoke( Object proxy, Method method, Object[] args ) throws Throwable     {       //在转调具体目标对象之前，可以执行一些功能处理    //转调具体目标对象的方法    return method.invoke( proxied, args);      //在转调具体目标对象之后，可以执行一些功能处理  }    }
  • 创建代理对象，调用者直接使用该对象即可：
RealSubject real = new RealSubject();   Subject proxySubject = (Subject)Proxy.newProxyInstance(Subject.class.getClassLoader(),      new Class[]{Subject.class},      new ProxyHandler(real));    proxySubject.doSomething();

转自：http://blog.csdn.net/u010425776/article/details/79211117
文章有不当之处，欢迎指正，你也可以关注我的微信公众号：好好学java，获取java等优质视频教程、学习资源。

原文地址：http://blog.51cto.com/sihai/2071497

时间： 2024-10-30 08:17:33

设计模式——开发常用的设计模式梳理的相关文章

最常用的设计模式

http://www.cnblogs.com/fora/archive/2011/04/29/2032829.html 最常用的设计模式 最常用的设计模式设计模式通常是对于某一类的软件设计问题的可重用的解决方案,将设计模式引入软件设计和开发过程,其目的就在于要充分利用已有的软件开发经验. 最常用的设计模式根据我的经验我把我经常用到的设计模式在这里做个总结,按照我的经验,它们的排序如下:1)单件模式.2)抽象工厂模式和工厂模式.3)适配器模式.4)装饰模式.5)观察者模式.6)外观模式 其他模式目

什么是设计模式？常见的设计模式有哪些？

设计模式是众多软件开发人员经过长期的软件开发过程中总结得来的.针对的一般性问题的通用解决方案,是一套被分类编目的.软件开发人员都知晓的.可被反复利用的.代码设计经验的总结. 使用设计模式可以提高代码的复用.避免程序大量修改从而保证代码的可靠性,同时使代码更容易被他人理解.显然设计模式不管是对自己.对他人还是对系统都是有益的,设计模式使得代码编制真正的工程化,是软件工程的基石. 在Gang of Four中总结了23种经典的设计模式,常用的设计模式有:单例模式.工厂模式.观察者模.适配器模式.亨元

IOS开发常用设计模式

IOS开发常用设计模式 说起设计模式,感觉自己把握不了笔头,所以单拿出iOS开发中的几种常用设计模式谈一下. 单例模式(Singleton) 概念:整个应用或系统只能有该类的一个实例 在iOS开发我们经常碰到只需要某类一个实例的情况,最常见的莫过于对硬件参数的访问类,比如UIAccelerometer.这个类可以帮助我们获得硬件在各个方向轴上的加速度,但是我们仅仅需要它的一个实例就够了,再多,只会浪费内存. 所以苹果提供了一个UIAccelerometer的实例化方法+sharedAcceler

iOS开发中常用的设计模式

常用的设计模式(一)代理模式应用场景:当一个类的某些功能需要由别的类来实现,但是又不确定具体会是哪个类实现.优势:解耦合敏捷原则:开放-封闭原则实例:tableview的 数据源delegate,通过和protocol的配合,完成委托诉求.列表row个数delegate自定义的delegate (二)观察者模式应用场景:一般为model层对,controller和view进行的通知方式,不关心谁去接收,只负责发布信息.优势:解耦合敏捷原则:接口隔离原则,开放-封闭原则实例:Notificatio

最常用的设计模式（单例模式）

记得刚开始涉足程序的时候, 去笔试 ,发现有一个笔试题经常粗线,写一个单例模式的基本实现, 当时没研究设计模式也就不知为何物, 到今日  , 才发现它已成为我日常开发最常用的一种设计模式. 我写的所有设计模式的代码都会用java 呈现, 虽然第一个学习的是c++但是 最开始作为工作的是java,并且有点偏好java 单例模式 , 意思就是 整个系统仅只有此类的一个实力, 当然这只是狭义的单例,经常看到变种的单例是允许,创建指定数量的实例的 单例模式是一种创建型模式. 它是优化的一种策划, 避免重

几种常用的设计模式介绍

几种常用的设计模式介绍                                         1.    设计模式的起源 最早提出“设计模式”概念的是建筑设计大师亚力山大Alexander.在1970年他的<建筑的永恒之道>里描述了投计模式的发现,因为它已经存在了千百年之久,而现代才被通过大量的研究而被发现. 在<建筑的永恒之道>里这样描述:模式是一条由三个部分组成的通用规则:它表示了一个特定环境.一类问题和一个解决方案之间的关系.每一个模式描述了一个不断重复发生的问题,

【动力节点java培训】J2ee常用的设计模式

[动力节点java培训]J2ee常用的设计模式 Java中的23种设计模式: Factory(工厂模式),      Builder(建造模式),      Factory Method(工厂方法模式), Prototype(原始模型模式),Singleton(单例模式),    Facade(门面模式), Adapter(适配器模式),    Bridge(桥梁模式),       Composite(合成模式), Decorator(装饰模式),    Flyweight(享元模式),   

《.NET 设计规范》第 9 章：常用的设计模式

第 9 章:常用的设计模式 9.1 聚合组件 考虑为常用的特性域提供聚合组件. 要用聚合组件来对高层的概念(物理对象)进行建模,而不是对系统级的任务进行建模. 要让聚合组件的名字与众所周知的系统实体相对应,比如 MessageQueue.Process 或 EventLog,这样就能使类型更加引人注目. 要在设计聚合组件时使初始化尽可能地简单,这样用户只需进行简单的初始化就可以使用组件.如果某一项初始化是必需的,那么由于没有对组件进行初始化而引发的异常应该明确地告诉用户应该怎么做. 不要要求聚合

j2ee常用的设计模式

总共23种,分为三大类:创建型,结构型,行为型 我只记得其中常用的6.7种,分别是: 创建型(工厂.工厂方法.抽象工厂.单例) 结构型(包装.适配器,组合,代理) 行为(观察者,模版,策略) 然后再针对你熟悉的模式谈谈你的理解即可. Java中的23种设计模式: Factory(工厂模式),      Builder(建造模式),       Factory Method(工厂方法模式), Prototype(原始模型模式),Singleton(单例模式),    Facade(门面模式), A