初探Java设计模式5:一文了解Spring涉及到的9种设计模式

本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到个人仓库里查看前端

https://github.com/h2pl/Java-Tutorialjava

喜欢的话麻烦点下Star、fork哈node

文章也将发表在个人我的博客,阅读体验更佳:python

www.how2playlife.comgit

本文是微信公众号【Java技术江湖】的《夯实Java基础系列博文》其中一篇,本文部份内容来源于网络,为了把本文主题讲得清晰透彻,也整合了不少我认为不错的技术博客内容,引用其中了一些比较好的博客文章,若有侵权,请联系做者。该系列博文会告诉你如何从入门到进阶,一步步地学习Java基础知识,并上手进行实战,接着了解每一个Java知识点背后的实现原理,更完整地了解整个Java技术体系,造成本身的知识框架。为了更好地总结和检验你的学习成果,本系列文章也会提供每一个知识点对应的面试题以及参考答案。程序员

若是对本系列文章有什么建议,或者是有什么疑问的话,也能够关注公众号【Java技术江湖】联系做者,欢迎你参与本系列博文的创做和修订github

设计模式做为工做学习中的枕边书,却时常处于勤说不用的尴尬境地,也不是咱们时常忘记,只是一直没有记忆。面试

今天,螃蟹在IT学习者网站就设计模式的内在价值作一番探讨,并以spring为例进行讲解,只有领略了其设计的思想理念,才能在工做学习中运用到“无形”。算法

Spring做为业界的经典框架,不管是在架构设计方面,仍是在代码编写方面,都堪称行内典范。好了,话很少说,开始今天的内容。spring

spring中经常使用的设计模式达到九种,咱们举例说明:

第一种:简单工厂

又叫作静态工厂方法(StaticFactory Method)模式,但不属于23种GOF设计模式之一。 简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该建立哪个产品类。 spring中的BeanFactory就是简单工厂模式的体现,根据传入一个惟一的标识来得到bean对象,可是否是在传入参数后建立仍是传入参数前建立这个要根据具体状况来定。以下配置,就是在 HelloItxxz 类中建立一个 itxxzBean。

<beans>复制代码
    <bean id="singletonBean" >复制代码
        <constructor-arg>复制代码
            <value>Hello! 这是singletonBean!value>复制代码
        </constructor-arg>复制代码
   </ bean>复制代码
    <bean id="itxxzBean"复制代码
        singleton="false">复制代码
        <constructor-arg>复制代码
            <value>Hello! 这是itxxzBean! value>复制代码
        </constructor-arg>复制代码
    </bean>复制代码
</beans>复制代码

第二种:工厂方法(Factory Method)

一般由应用程序直接使用new建立新的对象,为了将对象的建立和使用相分离,采用工厂模式,即应用程序将对象的建立及初始化职责交给工厂对象。

通常状况下,应用程序有本身的工厂对象来建立bean.若是将应用程序本身的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。

螃蟹就以工厂方法中的静态方法为例讲解一下:

import java.util.Random;复制代码
public class StaticFactoryBean {复制代码
      public static Integer createRandom() {复制代码
           return new Integer(new Random().nextInt());复制代码
       }复制代码
}复制代码

建一个config.xm配置文件,将其归入Spring容器来管理,须要经过factory-method指定静态方法名称

<bean id="random"复制代码
factory-method="createRandom" //createRandom方法必须是static的,才能找到 scope="prototype"复制代码
/>复制代码

测试:

public static void main(String[] args) {
          //调用getBean()时,返回随机数.若是没有指定factory-method,会返回StaticFactoryBean的实例,即返回工厂Bean的实例       XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml"));       System.out.println("我是IT学习者建立的实例:"+factory.getBean("random").toString());复制代码
}复制代码

第三种:单例模式(Singleton)

保证一个类仅有一个实例,并提供一个访问它的全局访问点。 spring中的单例模式完成了后半句话,即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例,这是由于spring管理的是是任意的java对象。 核心提示点:Spring下默认的bean均为singleton,能够经过singleton=“true|false” 或者 scope=“?”来指定

第四种:适配器(Adapter)

在Spring的Aop中,使用的Advice(通知)来加强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式(一、JDK动态代理。二、CGLib字节码生成技术代理。)对类进行方法级别的切面加强,即,生成被代理类的代理类, 并在代理类的方法前,设置拦截器,经过执行拦截器重的内容加强了代理方法的功能,实现的面向切面编程。

Adapter类接口

public interface AdvisorAdapter {复制代码
boolean supportsAdvice(Advice advice);复制代码
      MethodInterceptor getInterceptor(Advisor advisor);复制代码
} **MethodBeforeAdviceAdapter类**,Adapter复制代码
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {复制代码
      public boolean supportsAdvice(Advice advice) {复制代码
            return (advice instanceof MethodBeforeAdvice);复制代码
      }复制代码
      public MethodInterceptor getInterceptor(Advisor advisor) {复制代码
            MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();复制代码
      return new MethodBeforeAdviceInterceptor(advice);复制代码
      }复制代码
}复制代码

第五种:包装器(Decorator)

在咱们的项目中遇到这样一个问题:咱们的项目须要链接多个数据库,并且不一样的客户在每次访问中根据须要会去访问不一样的数据库。咱们以往在spring和hibernate框架中老是配置一个数据源,于是sessionFactory的dataSource属性老是指向这个数据源而且恒定不变,全部DAO在使用sessionFactory的时候都是经过这个数据源访问数据库。

可是如今,因为项目的须要,咱们的DAO在访问sessionFactory的时候都不得不在多个数据源中不断切换,问题就出现了:如何让sessionFactory在执行数据持久化的时候,根据客户的需求可以动态切换不一样的数据源?咱们能不能在spring的框架下经过少许修改获得解决?是否有什么设计模式能够利用呢? 

首先想到在spring的applicationContext中配置全部的dataSource。这些dataSource多是各类不一样类型的,好比不一样的数据库:Oracle、SQL Server、MySQL等,也多是不一样的数据源:好比apache 提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean等。而后sessionFactory根据客户的每次请求,将dataSource属性设置成不一样的数据源,以到达切换数据源的目的。

spring中用到的包装器模式在类名上有两种表现:一种是类名中含有Wrapper,另外一种是类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。 

第六种:代理(Proxy)

为其余对象提供一种代理以控制对这个对象的访问。  从结构上来看和Decorator模式相似,但Proxy是控制,更像是一种对功能的限制,而Decorator是增长职责。 spring的Proxy模式在aop中有体现,好比JdkDynamicAopProxy和Cglib2AopProxy。 

第七种:观察者(Observer)

定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,全部依赖于它的对象都获得通知并被自动更新。spring中Observer模式经常使用的地方是listener的实现。如ApplicationListener。 

第八种:策略(Strategy)

定义一系列的算法,把它们一个个封装起来,而且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。 spring中在实例化对象的时候用到Strategy模式在SimpleInstantiationStrategy中有以下代码说明了策略模式的使用状况: 

第九种:模板方法(Template Method)

定义一个操做中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。Template Method模式通常是须要继承的。这里想要探讨另外一种对Template Method的理解。

spring中的JdbcTemplate,在用这个类时并不想去继承这个类,由于这个类的方法太多,可是咱们仍是想用到JdbcTemplate已有的稳定的、公用的数据库链接,那么咱们怎么办呢?咱们能够把变化的东西抽出来做为一个参数传入JdbcTemplate的方法中。可是变化的东西是一段代码,并且这段代码会用到JdbcTemplate中的变量。

怎么办?那咱们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法,咱们去实现这个方法,就把变化的东西集中到这里了。而后咱们再传入这个回调对象到JdbcTemplate,从而完成了调用。这多是Template Method不须要继承的另外一种实现方式吧。 

本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到个人仓库里查看

https://github.com/h2pl/Java-Tutorial

喜欢的话麻烦点下Star、fork哈

文章也将发表在个人我的博客,阅读体验更佳:

www.how2playlife.com

结构型模式

前面建立型模式介绍了建立对象的一些设计模式,这节介绍的结构型模式旨在经过改变代码结构来达到解耦的目的,使得咱们的代码容易维护和扩展。

代理模式

第一个要介绍的代理模式是最常使用的模式之一了,用一个代理来隐藏具体实现类的实现细节,一般还用于在真实的实现的先后添加一部分逻辑。

既然说是代理,那就要对客户端隐藏真实实现,由代理来负责客户端的全部请求。固然,代理只是个代理,它不会完成实际的业务逻辑,而是一层皮而已,可是对于客户端来讲,它必须表现得就是客户端须要的真实实现。

理解代理这个词,这个模式其实就简单了。

public interface FoodService {
    Food makeChicken();
    Food makeNoodle();
}

public class FoodServiceImpl implements FoodService {
    public Food makeChicken() {
          Food f = new Chicken()
        f.setChicken("1kg");
          f.setSpicy("1g");
          f.setSalt("3g");
        return f;
    }
    public Food makeNoodle() {
        Food f = new Noodle();
        f.setNoodle("500g");
        f.setSalt("5g");
        return f;
    }
}

// 代理要表现得“就像是”真实实现类,因此须要实现 FoodService
public class FoodServiceProxy implements FoodService {

    // 内部必定要有一个真实的实现类,固然也能够经过构造方法注入
    private FoodService foodService = new FoodServiceImpl();

    public Food makeChicken() {
        System.out.println("咱们立刻要开始制做鸡肉了");

        // 若是咱们定义这句为核心代码的话,那么,核心代码是真实实现类作的,
        // 代理只是在核心代码先后作些“无足轻重”的事情
        Food food = foodService.makeChicken();

        System.out.println("鸡肉制做完成啦,加点胡椒粉"); // 加强
          food.addCondiment("pepper");

        return food;
    }
    public Food makeNoodle() {
        System.out.println("准备制做拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制做完成啦")
        return food;
    }
}
复制代码

客户端调用,注意,咱们要用代理来实例化接口:

// 这里用代理类来实例化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();
复制代码

咱们发现没有,代理模式说白了就是作 “方法包装” 或作 “方法加强”。在面向切面编程中,算了仍是不要吹捧这个名词了,在 AOP 中,其实就是动态代理的过程。好比 Spring 中,咱们本身不定义代理类,可是 Spring 会帮咱们动态来定义代理,而后把咱们定义在 @Before、@After、@Around 中的代码逻辑动态添加到代理中。

说到动态代理,又能够展开说 …… Spring 中实现动态代理有两种,一种是若是咱们的类定义了接口,如 UserService 接口和 UserServiceImpl 实现,那么采用 JDK 的动态代理,感兴趣的读者能够去看看 java.lang.reflect.Proxy 类的源码;另外一种是咱们本身没有定义接口的,Spring 会采用 CGLIB 进行动态代理,它是一个 jar 包,性能还不错。

适配器模式

说完代理模式,说适配器模式,是由于它们很类似,这里能够作个比较。

适配器模式作的就是,有一个接口须要实现,可是咱们现成的对象都不知足,须要加一层适配器来进行适配。

适配器模式整体来讲分三种:默认适配器模式、对象适配器模式、类适配器模式。先不急着分清楚这几个,先看看例子再说。

默认适配器模式

首先,咱们先看看最简单的适配器模式默认适配器模式(Default Adapter)是怎么样的。

咱们用 Appache commons-io 包中的 FileAlterationListener 作例子,此接口定义了不少的方法,用于对文件或文件夹进行监控,一旦发生了对应的操做,就会触发相应的方法。

public interface FileAlterationListener {
    void onStart(final FileAlterationObserver observer);
    void onDirectoryCreate(final File directory);
    void onDirectoryChange(final File directory);
    void onDirectoryDelete(final File directory);
    void onFileCreate(final File file);
    void onFileChange(final File file);
    void onFileDelete(final File file);
    void onStop(final FileAlterationObserver observer);
}
复制代码

此接口的一大问题是抽象方法太多了,若是咱们要用这个接口,意味着咱们要实现每个抽象方法,若是咱们只是想要监控文件夹中的文件建立文件删除事件,但是咱们仍是不得不实现全部的方法,很明显,这不是咱们想要的。

因此,咱们须要下面的一个适配器,它用于实现上面的接口,可是全部的方法都是空方法,这样,咱们就能够转而定义本身的类来继承下面这个类便可。

public class FileAlterationListenerAdaptor implements FileAlterationListener {

    public void onStart(final FileAlterationObserver observer) {
    }

    public void onDirectoryCreate(final File directory) {
    }

    public void onDirectoryChange(final File directory) {
    }

    public void onDirectoryDelete(final File directory) {
    }

    public void onFileCreate(final File file) {
    }

    public void onFileChange(final File file) {
    }

    public void onFileDelete(final File file) {
    }

    public void onStop(final FileAlterationObserver observer) {
    }
}
复制代码

好比咱们能够定义如下类,咱们仅仅须要实现咱们想实现的方法就能够了:

public class FileMonitor extends FileAlterationListenerAdaptor {
    public void onFileCreate(final File file) {
        // 文件建立
        doSomething();
    }

    public void onFileDelete(final File file) {
        // 文件删除
        doSomething();
    }
}
复制代码

固然,上面说的只是适配器模式的其中一种,也是最简单的一种,无需多言。下面,再介绍“正统的”适配器模式。

对象适配器模式

来看一个《Head First 设计模式》中的一个例子,我稍微修改了一下,看看怎么将鸡适配成鸭,这样鸡也能当鸭来用。由于,如今鸭这个接口,咱们没有合适的实现类能够用,因此须要适配器。

public interface Duck {
    public void quack(); // 鸭的呱呱叫
      public void fly(); // 飞
}

public interface Cock {
    public void gobble(); // 鸡的咕咕叫
      public void fly(); // 飞
}

public class WildCock implements Cock {
    public void gobble() {
        System.out.println("咕咕叫");
    }
      public void fly() {
        System.out.println("鸡也会飞哦");
    }
}
复制代码

鸭接口有 fly() 和 quare() 两个方法,鸡 Cock 若是要冒充鸭,fly() 方法是现成的,可是鸡不会鸭的呱呱叫,没有 quack() 方法。这个时候就须要适配了:

// 毫无疑问,首先,这个适配器确定须要 implements Duck,这样才能当作鸭来用
public class CockAdapter implements Duck {

    Cock cock;
    // 构造方法中须要一个鸡的实例,此类就是将这只鸡适配成鸭来用
      public CockAdapter(Cock cock) {
        this.cock = cock;
    }

    // 实现鸭的呱呱叫方法
      @Override
      public void quack() {
        // 内部实际上是一只鸡的咕咕叫
        cock.gobble();
    }

      @Override
      public void fly() {
        cock.fly();
    }
}
复制代码

客户端调用很简单了:

public static void main(String[] args) {
    // 有一只野鸡
      Cock wildCock = new WildCock();
      // 成功将野鸡适配成鸭
      Duck duck = new CockAdapter(wildCock);
      ...
}
复制代码

到这里,你们也就知道了适配器模式是怎么回事了。无非是咱们须要一只鸭,可是咱们只有一只鸡,这个时候就须要定义一个适配器,由这个适配器来充当鸭,可是适配器里面的方法仍是由鸡来实现的。

咱们用一个图来简单说明下:

上图应该仍是很容易理解的,我就不作更多的解释了。下面,咱们看看类适配模式怎么样的。

类适配器模式

废话少说,直接上图:

看到这个图,你们应该很容易理解的吧,经过继承的方法,适配器自动得到了所须要的大部分方法。这个时候,客户端使用更加简单,直接 Target t = new SomeAdapter(); 就能够了。

适配器模式总结

  1. 类适配和对象适配的异同
> 一个采用继承,一个采用组合;
    > 
    > 类适配属于静态实现,对象适配属于组合的动态实现,对象适配须要多实例化一个对象。
    > 
    > 整体来讲,对象适配用得比较多。复制代码
  1. 适配器模式和代理模式的异同
比较这两种模式,实际上是比较对象适配器模式和代理模式,在代码结构上,它们很类似,都须要一个具体的实现类的实例。可是它们的目的不同,代理模式作的是加强原方法的活;适配器作的是适配的活,为的是提供“把鸡包装成鸭,而后当作鸭来使用”,而鸡和鸭它们之间本来没有继承关系。复制代码

桥梁模式

理解桥梁模式,其实就是理解代码抽象和解耦。

咱们首先须要一个桥梁,它是一个接口,定义提供的接口方法。

public interface DrawAPI {
   public void draw(int radius, int x, int y);
}
复制代码

而后是一系列实现类:

public class RedPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class GreenPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class BluePen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用蓝色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
复制代码

定义一个抽象类,此类的实现类都须要使用 DrawAPI:

public abstract class Shape {
   protected DrawAPI drawAPI;

   protected Shape(DrawAPI drawAPI){
      this.drawAPI = drawAPI;
   }
   public abstract void draw();    
}
复制代码

定义抽象类的子类:

// 圆形
public class Circle extends Shape {
   private int radius;

   public Circle(int radius, DrawAPI drawAPI) {
      super(drawAPI);
      this.radius = radius;
   }

   public void draw() {
      drawAPI.draw(radius, 0, 0);
   }
}
// 长方形
public class Rectangle extends Shape {
    private int x;
      private int y;

      public Rectangle(int x, int y, DrawAPI drawAPI) {
        super(drawAPI);
          this.x = x;
          this.y = y;
    }
      public void draw() {
      drawAPI.draw(0, x, y);
   }
}
复制代码

最后,咱们来看客户端演示:

public static void main(String[] args) {
    Shape greenCircle = new Circle(10, new GreenPen());
      Shape redRectangle = new Rectangle(4, 8, new RedPen());

      greenCircle.draw();
      redRectangle.draw();
}
复制代码

可能你们看上面一步步还不是特别清晰,我把全部的东西整合到一张图上:

这回你们应该就知道抽象在哪里,怎么解耦了吧。桥梁模式的优势也是显而易见的,就是很是容易进行扩展。

本节引用了这里的例子,并对其进行了修改。

装饰模式

要把装饰模式说清楚明白,不是件容易的事情。也许读者知道 Java IO 中的几个类是典型的装饰模式的应用,可是读者不必定清楚其中的关系,也许看完就忘了,但愿看完这节后,读者能够对其有更深的感悟。

首先,咱们先看一个简单的图,看这个图的时候,了解下层次结构就能够了:

咱们来讲说装饰模式的出发点,从图中能够看到,接口 Component 其实已经有了 ConcreteComponentA 和 ConcreteComponentB 两个实现类了,可是,若是咱们要加强这两个实现类的话,咱们就能够采用装饰模式,用具体的装饰器来装饰实现类,以达到加强的目的。

从名字来简单解释下装饰器。既然说是装饰,那么每每就是添加小功能这种,并且,咱们要知足能够添加多个小功能。最简单的,代理模式就能够实现功能的加强,可是代理不容易实现多个功能的加强,固然你能够说用代理包装代理的方式,可是那样的话代码就复杂了。

首先明白一些简单的概念,从图中咱们看到,全部的具体装饰者们 ConcreteDecorator 均可以做为 Component 来使用,由于它们都实现了 Component 中的全部接口。它们和 Component 实现类 ConcreteComponent 的区别是,它们只是装饰者,起装饰做用,也就是即便它们看上去牛逼轰轰,可是它们都只是在具体的实现中加了层皮来装饰而已。

注意这段话中混杂在各个名词中的 Component 和 Decorator,别搞混了。

下面来看看一个例子,先把装饰模式弄清楚,而后再介绍下 java io 中的装饰模式的应用。

最近大街上流行起来了“快乐柠檬”,咱们把快乐柠檬的饮料分为三类:红茶、绿茶、咖啡,在这三大类的基础上,又增长了许多的口味,什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等,每家店都有很长的菜单,可是仔细看下,其实原料也没几样,可是能够搭配出不少组合,若是顾客须要,不少没出如今菜单中的饮料他们也是能够作的。

在这个例子中,红茶、绿茶、咖啡是最基础的饮料,其余的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。固然,在开发中,咱们确实能够像门店同样,开发这些类:LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......可是,很快咱们就发现,这样子干确定是不行的,这会致使咱们须要组合出全部的可能,并且若是客人须要在红茶中加双份柠檬怎么办?三份柠檬怎么办?万一有个变态要四份柠檬,因此这种作法是给本身找加班的。

不说废话了,上代码。

首先,定义饮料抽象基类:

public abstract class Beverage {
      // 返回描述
      public abstract String getDescription();
      // 返回价格
      public abstract double cost();
}
复制代码

而后是三个基础饮料实现类,红茶、绿茶和咖啡:

public class BlackTea extends Beverage {
      public String getDescription() {
        return "红茶";
    }
      public double cost() {
        return 10;
    }
}
public class GreenTea extends Beverage {
    public String getDescription() {
        return "绿茶";
    }
      public double cost() {
        return 11;
    }
}
...// 咖啡省略
复制代码

定义调料,也就是装饰者的基类,此类必须继承自 Beverage:

// 调料
public abstract class Condiment extends Beverage {

}
复制代码

而后咱们来定义柠檬、芒果等具体的调料,它们属于装饰者,毫无疑问,这些调料确定都须要继承 Condiment 类:

public class Lemon extends Condiment {
    private Beverage bevarage;
      // 这里很关键,须要传入具体的饮料,如须要传入没有被装饰的红茶或绿茶,
      // 固然也能够传入已经装饰好的芒果绿茶,这样能够作芒果柠檬绿茶
      public Lemon(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        // 装饰
        return bevarage.getDescription() + ", 加柠檬";
    }
      public double cost() {
          // 装饰
        return beverage.cost() + 2; // 加柠檬须要 2 元
    }
}
public class Mango extends Condiment {
    private Beverage bevarage;
      public Mango(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        return bevarage.getDescription() + ", 加芒果";
    }
      public double cost() {
        return beverage.cost() + 3; // 加芒果须要 3 元
    }
}
...// 给每一种调料都加一个类
复制代码

看客户端调用:

public static void main(String[] args) {
      // 首先,咱们须要一个基础饮料,红茶、绿茶或咖啡
    Beverage beverage = new GreenTea();
      // 开始装饰
      beverage = new Lemon(beverage); // 先加一份柠檬
      beverage = new Mongo(beverage); // 再加一份芒果

      System.out.println(beverage.getDescription() + " 价格:¥" + beverage.cost());
      //"绿茶, 加柠檬, 加芒果 价格:¥16"
}
复制代码

若是咱们须要芒果珍珠双份柠檬红茶:

Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));
复制代码

是否是很变态?

看看下图可能会清晰一些:

到这里,你们应该已经清楚装饰模式了吧。

下面,咱们再来讲说 java IO 中的装饰模式。看下图 InputStream 派生出来的部分类:

咱们知道 InputStream 表明了输入流,具体的输入来源能够是文件(FileInputStream)、管道(PipedInputStream)、数组(ByteArrayInputStream)等,这些就像前面奶茶的例子中的红茶、绿茶,属于基础输入流。

FilterInputStream 承接了装饰模式的关键节点,其实现类是一系列装饰器,好比 BufferedInputStream 表明用缓冲来装饰,也就使得输入流具备了缓冲的功能,LineNumberInputStream 表明用行号来装饰,在操做的时候就能够取得行号了,DataInputStream 的装饰,使得咱们能够从输入流转换为 java 中的基本类型值。

固然,在 java IO 中,若是咱们使用装饰器的话,就不太适合面向接口编程了,如:

InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));
复制代码

这样的结果是,InputStream 仍是不具备读取行号的功能,由于读取行号的方法定义在 LineNumberInputStream 类中。

咱们应该像下面这样使用:

DataInputStream is = new DataInputStream(
                              new BufferedInputStream(
                                  new FileInputStream("")));
复制代码

因此说嘛,要找到纯的严格符合设计模式的代码仍是比较难的。

门面模式

门面模式(也叫外观模式,Facade Pattern)在许多源码中有使用,好比 slf4j 就能够理解为是门面模式的应用。这是一个简单的设计模式,咱们直接上代码再说吧。

首先,咱们定义一个接口:

public interface Shape {
   void draw();
}
复制代码

定义几个实现类:

public class Circle implements Shape {

   @Override
   public void draw() {
      System.out.println("Circle::draw()");
   }
}

public class Rectangle implements Shape {

   @Override
   public void draw() {
      System.out.println("Rectangle::draw()");
   }
}
复制代码

客户端调用:

public static void main(String[] args) {
    // 画一个圆形
      Shape circle = new Circle();
      circle.draw();

      // 画一个长方形
      Shape rectangle = new Rectangle();
      rectangle.draw();
}
复制代码

以上是咱们常写的代码,咱们须要画圆就要先实例化圆,画长方形就须要先实例化一个长方形,而后再调用相应的 draw() 方法。

下面,咱们看看怎么用门面模式来让客户端调用更加友好一些。

咱们先定义一个门面:

public class ShapeMaker {
   private Shape circle;
   private Shape rectangle;
   private Shape square;

   public ShapeMaker() {
      circle = new Circle();
      rectangle = new Rectangle();
      square = new Square();
   }

  /**
   * 下面定义一堆方法,具体应该调用什么方法,由这个门面来决定
   */

   public void drawCircle(){
      circle.draw();
   }
   public void drawRectangle(){
      rectangle.draw();
   }
   public void drawSquare(){
      square.draw();
   }
}
复制代码

看看如今客户端怎么调用:

public static void main(String[] args) {
  ShapeMaker shapeMaker = new ShapeMaker();

  // 客户端调用如今更加清晰了
  shapeMaker.drawCircle();
  shapeMaker.drawRectangle();
  shapeMaker.drawSquare();        
}
复制代码

门面模式的优势显而易见,客户端再也不须要关注实例化时应该使用哪一个实现类,直接调用门面提供的方法就能够了,由于门面类提供的方法的方法名对于客户端来讲已经很友好了。

组合模式

组合模式用于表示具备层次结构的数据,使得咱们对单个对象和组合对象的访问具备一致性。

直接看一个例子吧,每一个员工都有姓名、部门、薪水这些属性,同时还有下属员工集合(虽然可能集合为空),而下属员工和本身的结构是同样的,也有姓名、部门这些属性,同时也有他们的下属员工集合。

public class Employee {
   private String name;
   private String dept;
   private int salary;
   private List<Employee> subordinates; // 下属

   public Employee(String name,String dept, int sal) {
      this.name = name;
      this.dept = dept;
      this.salary = sal;
      subordinates = new ArrayList<Employee>();
   }

   public void add(Employee e) {
      subordinates.add(e);
   }

   public void remove(Employee e) {
      subordinates.remove(e);
   }

   public List<Employee> getSubordinates(){
     return subordinates;
   }

   public String toString(){
      return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
   }   
}
复制代码

一般,这种类须要定义 add(node)、remove(node)、getChildren() 这些方法。

这说的其实就是组合模式,这种简单的模式我就不作过多介绍了,相信各位读者也不喜欢看我写废话。

享元模式

英文是 Flyweight Pattern,不知道是谁最早翻译的这个词,感受这翻译真的很差理解,咱们试着强行关联起来吧。Flyweight 是轻量级的意思,享元分开来讲就是 共享 元器件,也就是复用已经生成的对象,这种作法固然也就是轻量级的了。

复用对象最简单的方式是,用一个 HashMap 来存放每次新生成的对象。每次须要一个对象的时候,先到 HashMap 中看看有没有,若是没有,再生成新的对象,而后将这个对象放入 HashMap 中。

这种简单的代码我就不演示了。

结构型模式总结

前面,咱们说了代理模式、适配器模式、桥梁模式、装饰模式、门面模式、组合模式和享元模式。读者是否能够分别把这几个模式说清楚了呢?在说到这些模式的时候,心中是否有一个清晰的图或处理流程在脑海里呢?

代理模式是作方法加强的,适配器模式是把鸡包装成鸭这种用来适配接口的,桥梁模式作到了很好的解耦,装饰模式从名字上就看得出来,适合于装饰类或者说是加强类的场景,门面模式的优势是客户端不须要关心实例化过程,只要调用须要的方法便可,组合模式用于描述具备层次结构的数据,享元模式是为了在特定的场景中缓存已经建立的对象,用于提升性能。

参考文章

转自https://javadoop.com/post/design-pattern

微信公众号

我的公众号:程序员黄小斜

​黄小斜是 985 硕士,阿里巴巴Java工程师,在自学编程、技术求职、Java学习等方面有丰富经验和独到看法,但愿帮助到更多想要从事互联网行业的程序员们。​做者专一于 JAVA 后端技术栈,热衷于分享程序员干货、学习经验、求职心得,以及自学编程和Java技术栈的相关干货。​黄小斜是一个斜杠青年,坚持学习和写做,相信终身学习的力量,但愿和更多的程序员交朋友,一块儿进步和成长!

原创电子书:关注微信公众号【程序员黄小斜】后回复【原创电子书】便可领取我原创的电子书《菜鸟程序员修炼手册:从技术小白到阿里巴巴Java工程师》这份电子书总结了我2年的Java学习之路,包括学习方法、技术总结、求职经验和面试技巧等内容,已经帮助不少的程序员拿到了心仪的offer!

程序员3T技术学习资源: 一些程序员学习技术的资源大礼包,关注公众号后,后台回复关键字 “资料” 便可免费无套路获取,包括Java、python、C++、大数据、机器学习、前端、移动端等方向的技术资料。

技术公众号:Java技术江湖

若是你们想要实时关注我更新的文章以及分享的干货的话,能够关注个人微信公众号【Java技术江湖】

这是一位阿里 Java 工程师的技术小站。做者黄小斜,专一 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!

Java工程师必备学习资源:关注公众号后回复”Java“便可领取 Java基础、进阶、项目和架构师等免费学习资料,更有数据库、分布式、微服务等热门技术学习视频,内容丰富,兼顾原理和实践,另外也将赠送做者原创的Java学习指南、Java程序员面试指南等干货资源

个人公众号

相关文章
相关标签/搜索