zoukankan      html  css  js  c++  java
  • Java 23种设计模式详尽分析与实例解析之二--结构型模式

    Java设计模式

    结构型模式

    适配器模式


    模式动机:在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配器模式。通常情况下,客户端可以通过目标类的接口访问它所提供的服务。又是,现有的类可以满足客户的功能需要,但是它所提供的接口不一定是客户类所期望的,这可能是现有类中方法名与目标类中定义的方法不一致等原因所导致的。在这种情况下,现有的接口需要转化为客户类所期望的接口,这样保证了对现有的重用。如不这样的转化,客户类就不能现有类所提供的功能,适配器模式可以完成这样的转化。在适配器模式中可以定义一个包装类,包装不兼容接口的对象,这个包装类指的就是适配器,它所包装的对象就是适配者,即被适配的类。

        适配器提供客户类需要的接口,适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用。也就是说:当客户类调用适配器的方法时,在适配器内部将调用适配者类的方法,而整个过程对用户是透明的,客户类不直接访问适配者。因此,适配器可以使得由于接口而不能交互的类可以一起工作。

    模式定义:将一个类的接口转换成客户希望的另外接口。适配器模式使得原本由于接口不兼容而一起工作的那些类可以一起工作。

    模式结构:


     

    模式分析:从上图可以看出,适配器模式的结构图中包含三类对象:目标抽象类,适配器,适配者类。

    (1)、Target(目标抽象类):目标抽象类定义客户所需接口,可以是一个抽象类或者接口,也可以是具体类。

    (2)、Adapter(适配器类):适配器可以调用另一个接口,作为一个转换器,对Adapter进而Target进行适配。适配器类是适配器模式的核心,在适配器模式中它通过继承Target并关联一个Adaptee对象使二者产生联系。

    (3)、Adaptee(适配者类):是陪着即被适配的角色,它定义了一个已经存在的接口,这个接口需要适配,适配者类一般是一个具体类,包含了客户希望使用的业务方法,在某些情况下可能没有适配者类的源代码。

    根据上图,在适配者模式中,客户端需要调用request()方法,而适配者类Adaptee没有该方法,但是它所提供的specificRequest()方法却是客户端所需要的。为了使客户端能够使用适配者类,需要提供一个包装类Adapter,即适配器类。这个包装类包装了一个适配者的实例,从而将客户端与适配者衔接起来,在适配器的request()方法中调用适配者的specificRequest()方法。因为适配器与适配者类是关联关系,所以这种适配器称为对象适配器模式。

    模式应用:

    1、  sun公司推出的JDBC数据库连接工具,每一个具体数据库引擎(如SQL Server、Oracle、MySQL)的JDBC驱动软件都是一个介于JDBC接口和数据库引擎接口之间的适配器软件。

    2、  Spring AOP框架中,对BeforeAdvice、AfterAdvice、ThrowsAdvice三种通知类型借助适配器模式来实现。

    3、  在JDK类库中也定义了一系列适配器类,如在com.sun.imageio.plugins.common包装ImageInputStream及其子类对象。

    桥接模式

    模式动机:设想如果绘制矩形、圆形、椭圆、正方形,至少需要四个形状类,但是如果绘制的图形需要具有不同的颜色,如:红色、绿色、蓝色等,此时至少有如下两种设计方案:

    第一种设计方案是为每一种形状都提供一套各种颜色的版本。

    第二种设计方案是根据实际需要对形状和颜色进行组合。

    对于有两个变化维度的系统,采用方案二来设计系统中类的个数更少,且系统扩展更为方便。设计方案二即是模式的应用。桥接将继承关系转换为关联关系,降低了类与类之间的耦合,减少了代码编写量。

    模式定义:将抽象部分与它的实现部分分离,使它们可以独立地变化。它是一种对象结构型模式,也称为接口模式。

    模式结构:


    模式分析:桥接模式包括四类角色:

    • Abstraction:抽象类

    • RefinedAbstraction:扩充抽象类

    • Implementor:实现类接口

    • ConcreteImplementor:具体实现类

    理解桥接模式,重点需要理解如何将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化。

    •抽象化:抽象化就是忽略一些信息,把不同的实体当作同样的实体对待。在面向对象中,将对象的共同性质抽取出来形成类的过程即为抽象化的过程。

    •实现化:针对抽象化给出的具体实现,就是实现化,抽象化与实现化是一对互逆的概念,实现化产生的对象比抽象化更具体,是对抽象化事物的进一步具体化的产物。

    •脱耦:脱耦就是将抽象化和实现化之间的耦合解脱开,或者说是将它们之间的强关联改换成弱关联,将两个角色之间的继承关系改为关联关系。桥接模式中的所谓脱耦,就是指在一个软件系统的抽象化和实现化之间使用关联关系(组合或者聚合关系)而不是继承关系,从而使两者可以相对独立地变化,这就是桥接模式的用意

    模式应用:

    1、JDBC驱动程序也是桥接模式的应用之一。使用JDBC驱动程序的应用系统就是抽象角色,而所使用的数据库是实现角色。一个JDBC驱动程序可以动态地将一个特定类型的数据库与一个Java应用程序绑定在一起,从而实现抽象角色与实现角色的动态耦合。

    组合模式

    模式动机:对于树形结构,当容器对象(如文件夹)的某一个方法被调用时,将遍历树形,寻找也这个方法的(可以是容器对象,也可以是叶子对象,如子文件夹和文件)并调用执行。(递归调用)

    由于容器对象和叶子对象在功能上的区别,在使用这些对象的客户端代码中必须有区别地对待容器对象和叶子对象,而实际上大多数情况下客户端希望一致地处理它们,因为对于这些对象的区别对待将会使得程序非常复杂。组合模式描述了如何将容器对象和叶子对象进行递归组合,使得用户在使用时无须对它们进行区分,可以一致地对待容器对象也叶子对象,这就是组合模式的模式动机。

    模式定义:组合多个对象形成树形结构以表示“整体—部分”的结构层次。组合模式对单对象(即叶子对象)和组合对象(即容器对象)的使用具有一致性。组合模式又称为“整体—部分”模式,属于对象的结构模式,它将对象组织到树状结构中,可以用来整体部分的关系。

    模式结构:


    模式分析:

    组合模式的关键是定义了一个抽象构件类,它既可以代表叶子,也可以代表容器,而客户端针对该抽象构件类进行,知道它到底表示的是叶子还是容器,可以对其进行统一处理。同时容器对象与抽象构件类之间还建立一个聚合关联关系,在容器对象中既可以包含也可以容器,以实现递归组合,形成一个树形结构。

    模式应用:

    1、  XML文档解析

    2、  操作系统中的目录结构是一个树形结构,因此在对文件和文件夹进行操作时可以应用组合模式,例如杀毒软件在查毒或杀毒时,既可以针对一个具体文件,也可以针对一个目录。如果是对目录查毒或杀毒,将递归处理目录中的每一个子目录和文件。

    3、  JDK的AWT/Swing是组合模式在Java类库中的一个典型实际应用

    装饰模式

    模式动机:一个有方式可以实现一个类或对象增加功能:一种是继承机制,使用继承机制是给现有类增加功能的一种有效途径,通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法。但是这种方法是静态的,用户不能控制增加行为的方式和时机。一种是关联机制,即将一个类的对象嵌入到另一个对象中,由另一个对象来决定是否调用嵌入对象的行为以便扩展自己的行为,我们称这个嵌入的对象为装饰器。

    装饰模式以对用户透明的方式动态地给一个对象附加上更多的责任,换言之,客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不需要创造更多子类的情况下,将对象的功能加以扩展。

    模式定义:动态地给一个对象增加一些额外的职责,就增加对象功能来说,装饰模式生成子类实现更为。其别名也可以称为包装器,与适配器的别名相同,但它们适用于不同的场合。装饰模式也称为油漆工模式,是一种对象结构型模式。

    模式结构:



    注:Component是定义一个对象接口,可以给这些对象动态地增加职责。ConcreteComponent是定义了一个具体的对象,也可以对这个对象增加职责。Decorator,装饰抽象类,继承了Component从外类来扩展Component类的功能,但对于Component来说,是无须知道Decorator存在的。至于ConcreteDecorator具体的装饰对象,起到Component职责的功能。

    模式分析:

    装饰模式包含如下角色:

    • Component: 抽象构件

    • ConcreteComponent: 具体构件

    • Decorator: 抽象装饰类

    • ConcreteDecorator: 具体装饰类

    与继承关系相比,关联关系的主要优势在于不会破坏类的封装性,而且继承是一种耦合度较大的静态关系,无法在程序运行时动态扩展。在软件开发阶段,关联关系虽然不会比继承关系减少编码量,但是到了软件维护阶段,由于关联关系使系统具有较好的松耦合性,因此使得系统更加容易维护。当然,关联关系的缺点是比继承关系要创建更多的对象。

    使用装饰模式来实现扩展比继承更加灵活,它以对客户透明的方式动态地给一个对象附加更多的责任。装饰模式可以在不需要创造更多子类的情况下,将对象的功能加以扩展。

    模式应用:

    1、装饰模式在JDK中最经典的实例就是Java IO。

    外观模式

    模式动机:考虑网站导航,打开网页首页时,有公司新闻、留言系统、产品介绍、在线论坛等导航,这样的话我们先通过导航定位到不同的页面,这样总比直接找到某一页面方便的多。考虑去茶馆喝茶的例子。我们比较下自己泡茶和去茶馆喝茶的区别?自己泡茶需要自行准备茶叶、茶具和开水,而去茶馆喝茶,最简单的方式就是跟服务员说想要一杯什么茶。正因为茶馆有服务员,顾客无须直接和茶叶、茶具和开水打交道,整个泡茶过程由服务员来完成,顾客只需要与服务员交互即可,非常简单省事。

    模式定义:外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

    模式结构:




    模式分析:根据“单一职责原则”,在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性,一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小,而达到该目标的途径之一就是引入外观对象,它为子系统的访问提供了一个简单而单一的入口。

    外观模式也是“迪米特法则”的体现,通过引入一个新的外观类可以降低原有系统的复杂度,同时客户类与子系统类的耦合度。

    模式应用:

    1、Session外观模式是外观模式在JavaEE框架中的应用。

    亨元模式

    用的不多,留着以后分析。。。。。。

    代理模式

    模式动机:在某些情况下,一个客户不想或者不能直接引用一个对象,此时可以通过一个称为“代理”的第三者来实现间接引用。可以在客户端和目标对象之间起到中介的作用,并且可以通过代理对象去掉客户端看到的内容和服务或者添加客户需要的额外服务。

    模式定义:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地引用,使其耦合松散,而且可以独立地改变它们之间的交互。

    模式结构:


    模式分析:代理模式的结构比较简单,其核心是代理类,为了让客户端能够一致地对待真实对象和代理对象。在代理模式中引入了抽象层。代理模式包括三个角色:

    (1)、Subject(抽象主题):它声明了真实主题和代理主题的共同接口,使得在任何使用真实主题的地方都可以使用代理主题(里氏代换原则,代理主题和真实主题实现了相同的接口),客户端通常需要针对抽象主题角色进行编程。

    (2)、Proxy(代理主题角色):代理主题角色内部包含了对真实主题的引用,从而可以在任何时候操作真实主题的对象;在代理主题角色中提供一个与真实主题角色相同的接口,以便在任何时候都可以替代真实主题;代理主题角色还可以控制对真实主题角色的使用,负责在需要的时候创建和删除真实主题对象,并对真实主题对象的使用甲乙约束。通常,在代理主题角色中,客户端在调用所引用的真实主题操作之前或之后还需要执行其他操作,而不仅仅是单纯调用真实主题对象的操作(如Spring AOP中增加日志或者统计执行时间的功能)。

    (3)、RealSubject(真实主题角色):它定义了代理角色所代表的真实对象,在真实主题角色中实现了真实的业务操作,客户端可以通过代理主题角色间接调用真实主题角色中定义的操作。

    模式应用:

    1、  Java RMI(远程方法调用)

    2、  Spring框架中的AOP技术也是代理的应用,在Spring AOP中应用了动态代理技术(Dynamic Proxy)技术。


    参考文献:

    1、大话设计模式

    2、设计模式的艺术之道--软件开发人员内功修炼之道。


  • 相关阅读:
    CodeForces 706C Hard problem
    CodeForces 706A Beru-taxi
    CodeForces 706B Interesting drink
    CodeForces 706E Working routine
    CodeForces 706D Vasiliy's Multiset
    CodeForces 703B Mishka and trip
    CodeForces 703C Chris and Road
    POJ 1835 宇航员
    HDU 4907 Task schedule
    HDU 4911 Inversion
  • 原文地址:https://www.cnblogs.com/fuhaots2009/p/3455250.html
Copyright © 2011-2022 走看看