引子
设计模式的六大原则
结构型设计模式
结构性设计模式描述 如何将类或者对象按某种布局组成更大的结构。
它分为类结构型模式和对象结构型模式,
前者采用继承机制来组织接口和类,
后者采用组合或者聚合组合对象。
由于组合关系或聚合关系比较继承关系耦合度低,满足“合成复合原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。
结构型模式分为以下7种:
代理模式(Proxy): 为某对象提供一种代理以控制对象的访问。即客户端通过代理简介的访问该对象,从而限制、增强或修改该对象的一些特征。
适配器模式(Adapter): 将一个类的接口转换成希望的另一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
桥接模式(Bridge): 将抽象和实现分离,使得他们可以独立变化。是用组合关系代替继承关系来实现的,从而降低了抽象和实现这两个可变维度的耦合度。
装饰模式(Decorator):动态的给对象正将一些职责,即增加其额外的功能。
外观模式(Facade):为多个复杂的子系统提供一个一致的接口,使得这些子系统更加容易被访问。
享元模式(Flyweight): 使用共享技术来有效的支持大量细粒度对象的复用。
组合模式(Composite):将对象组合成树状层次结构,使用户对单个对象和组合对象具有一致的访问性。
代理模式(Proxy)
有些情况下,一个客户不能或者不想直接访问目标对象,这是需要找一个中介帮忙完成某项任务,这个中介就是代理对象。
软件设计中使用代理模式的例子很多,如:因为安全需要屏蔽客户端直接访问真实对象,如单位内部的数据库等。
代理模式的定义与特点
定义:由于某些原因需要给对象提供一个代理以控制该对象的访问。这时,访问对象不合适或者不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介。
代理模式的主要优点:
- 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用;
- 代理模式可以扩展目标对象的功能;
- 代理模式将客户端与目标对象分离,在一定程度上降低了系统的耦合度。
主要缺点是:
- 客户端和目标对象之间添加代理,会造成请求处理速度变慢;
- 增加了系统的复杂度。
代理模式的结构和实现
结构比较简单,只要通过定义一个集成抽象主题的代理来包含真实主题,从而实现对真实主题的访问。
结构
主要角色
- 抽象主题:通过接口或者抽象类声明真实主题或者代理对象实现的业务方法。
- 真实主题:实现抽象主题中的具体业务,是代理对象所代表的的真实对象,是最终要引用的对象。
- 代理类:提供与真实主题相同的接口,其内部含有对真实主题的引用,他可以访问控制或者扩展真实主题的功能
1 | //抽象主题 |
1 | // 真实主题 |
1 | // 代理 |
1 | public class ProxyTest { |
代理模式的应用场景
前面分析了代理模式的结构与特点,现在分析以下的应用 场景 。
远程代理,这种方法通常是为了隐藏目标对象目标存在于不同地址空间的事实,方便客户端访问。例如,用户申请某些网盘空间时,会在用户的文件系统中建立一个虚拟的硬盘,用户访问虚拟硬盘时实际访问的是网盘空间。
虚拟代理,这种方式通常用于要创建的目标对象开销很大。例如,下载一个很大的图片需要很长时间,因某种计算比较复杂而短时间无法完成,这时可以先用小比例的虚拟代理替换真实的对象,消除用户对服务器慢的感觉。
安全代理,这种方式通常用于控制不同种类客户对真实对象的访问权限。
智能指引,主要用于调用目标对象时,代理附加一些额外的处理功能。例如,增加计算真实对象的引用次数的功能,这样当该对象没有被引用时,就可以自动释放它。
延迟加载,指为了提高系统的性能,延迟对目标的加载。例如,Hibernate 中就存在属性的延迟加载和关联表的延时加载。
代理模式的扩展
在前面介绍的代理模式中,代理类中包含了对真实主题引用,这种方式存在两个缺点。
1)真实主题与代理主题一一对应,增加真实主题也要增加代理。
2)设计代理以前真实主题必须事先存在,不太灵活。采用动态代理模式可以解决以上问题,如 SpringAOP,其结构图如图3-2所示。
参考
适配器模式
在现实生活中,经常出现两个对象因接口不兼容而不能再一起工作的实例,这时需要第三者进行适配。例如,讲中文的人同讲英文的人对话时需要一个翻译,用直流电的笔记本电脑接交流电源时需要一个电源适配器。
在软件设计中也可能出现:需要开发的具有某种业务功能的组件在现有的组件库中已经存在,但它们与当前系统的接口规范不兼容,如果重写开发这些组件成本又很高,这时用是适配器模式能很好地解决这些问题。
模式的定义与特点
适配器模式的定义如下:将一个类的接口转换成客户希望的另一个接口,使得原本由于接口不兼容而不能一起功能的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种,前者之间的耦合度比后者高,其要求程序员了解现有组件库中的相关的内部结构,所以应对相对较少些。
该模式的主要优点如下:
客户端通过适配器可以透明地调用目标接口。
复用了现存的类,程序员不需要修改原有代码而重用现有的适配者类。
将目标和适配这类解耦,解决了目标类和适配类接口不一致问题。
其缺点是:
对类适配器来说,更换适配器的实现过程比较复杂。
模式的结构与实现
含有以下角色
- 目标接口:当前系统业务期望的接口
- 适配类:现存组件库中的组件接口
- 适配器类:是一个适配器,通过继承或者引用适配者的对象,把适配类转换成目标接口
实现:
1 | // 目标接口 |
类适配器模式的代码如下:
1 | // 适配者接口 |
1 | //客户端代码 |
对象适配器模式的代码如下:
1 | // 对象适配器类 |
1 | // 客户端代码 |
说明:对象适配器模式中的“目标接口”和“适配者类”的代码同类适配器模式一样,只要修改适配器类和客户端的代码即可。
桥接模式(Bridge)
在现实生活中,某些具有两个或者多个维度的变化量,如图像可按形状分,也可按颜色分。
如果设计类似Ps这样的软件,如何去画不同形状和不同颜色的图像呢?如果用继承方式,m种形状和n种颜色的图形就有m*n种,不但对应的子类很多,而且扩展困难.
当然这样的例子还有很多,如不同颜色和字体的文字,不同品牌和功率的汽车,不同性别和职业的人。如果使用桥接模式就能很好的解决这些问题。
桥接模式的定义和特点
定义: 将抽象和实现分离,使得它们可以独立的变化。它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个可变维度的耦合度。
桥接模式的优点:
- 由于抽象和实现分离,所以扩展能力强
- 其 实现细节对客户透明
缺点:
由于聚合关系建立在抽象层,要求开发者针对抽象化进行设计与编程,增加了系统的理解与设计难度。
桥接模式的结构与实现
可以将抽象化部分与实现化部分分开,取消二者的继承关系;改用组合关系。
桥接模式包含以下主要角色:
1)抽象化角色:定义抽象类,并包含一个对实现化对象的引用。
2)扩展抽象化角色:是抽象化角色的子类,实现父类中的业务方法,并通过组合关系调用实现化角色中的业务方法。
3)实现化角色:定义是实现化角色的接口,供扩展抽象化角色调用。
4)具体实现化角色:给出实现化角色接口的具体实现。
桥接模式的应用场景
桥接模式通常适用于以下场景:
- 当一个类存在两个独立变化的维度,其这两个维度都需要进行扩展时。
- 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
- 当一个系统需要在结构的抽象画角色和具体化角色之间增加更多的灵活性时。
桥接模式的扩展
装饰模式
现实生活中,常常需要对现有产品增加新的功能或者美化其外观,如房子装修,相片加相框等。软件开发过程中,有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下,可以动态地扩展其功能。这些都可以采用装饰模式来实现。
装饰模式的定义和特点
定义: 指在不改变现有对象结构的情况下,动态地给该对象增加一些职责的模式,它属于对象结构型模式。
主要优点:
- 采用装饰模式扩展比采用继承扩展更加灵活。
- 可以设计出多个不同的具体装饰类,创造出多个不同行为的组合。
模式的结构:
1)抽象构件角色:定义一个抽象接口以规范准备接收附加责任的对象。
2)具体构件角色:实现抽象构件,通过装饰角色为其添加一些职责。
3)抽象装饰角色:继承抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能。
4)具体装饰角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任。
装饰模式的应用场景
前面讲解了关于装饰模式的结构与特点,下面介绍其适用的应用场景,装饰模式通常在以下几种情况使用。
- 当需要给一个现有类添加附加职责,而又不能采用生成子类的方法进行扩充时。例如,该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
- 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时,采用继承关系很难实现,而采用装饰模式却很好实现。
- 当对象的功能要求可以动态地添加,也可以再动态地撤销时。
装饰模式的变种
外观模式
现实生活中,常常存在办事较复杂的例子,如办房产证或者注册一家公司,有时候需要同多个部门联系,这时要有一个综合部门能解决一切手续问题就好了。
软件设计也是这样,当一个系统的功能越来越强,子系统会越来越多,客户对系统的访问也会越来越复杂。这是如果系统内部发生改变,客户端也要跟着改变,这违背了“开闭原则”,也违背了“迪米特原则”,所以有必要为多个子系统提供一个统一的接口,从而降低系统的耦合度,这就是外观模式的目标。
可以简单概括
如果一项业务需要和多个子系统交互,那么使用外观模式将多个子系统的调用放在这项业务内部。
外部需要使用这项业务的地方,只需要和外观模式进行访问。
外观模式的定义与特点
外观模式的定义:是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易的被访问的模式。该模式对外有一个统一的接口,外部应用程序不用关心内部子系统的具体细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性。
外观模式是“迪米特法则”的典型应用
优点
- 降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类
- 对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得系统使用起来更加容易。
- 降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程,因为编译一个子系统不会影响其他的子系统,也不会影响外观对象。
缺点:
- 不能很好的限制客户使用子系统类
- 增加新的子系统可能需要修改外观类或者客户端的源代码,违背了“开闭原则”。
外观模式的结构与实现
主要 定义了一个高层接口。它包含了对各个子系统的引用,客户端可以通过它访问各个子系统的功能。
模式的结构:
1)外观(Facade)角色:为多个子系统对外提供一个共同的接口。
2)子系统(Sub System)角色:实现系统的部分功能,客户可以通过外观角色访问它。
3)客户(Client)角色:通过一个外观角色访问各个子系统的功能。
外观模式的场景应用
通常在以下情况下可以考虑使用外观模式。
1)对分层结构系统构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
2)当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问。
3)当客户端与多个子系统之间存在很大的联系时,引入外观模式可将它们分离,从而提高子系统的独立性和可移植性。
享元模式
在面向对象程序设计过程中,有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源,它是系统性能提高的一个瓶颈。例如,围棋和五子棋中的黑白棋子,图像中的坐标点或颜色,局域网中的路由器、交换机和集线器,教室里的桌子和凳子等。这些对象有很多相似的地方,如果能把它们相同的部分提取出来共享,则能节省大量的系统资源,这就是享元模式的产生背景。
享元模式的定义与特点
享元模式的定义:运用共享技术来有効地支持大量细粒度对象的复用。它通过共享已经存在的又橡来大幅度减少需要创建的对象数量、避免大量相似类的开销,从而提高系统资源的利用率。
享元模式的主要优点是:相同对象只要保存一份,这降低了系统中对象的数量,从而降低了系统中细粒度对象给内存带来的压力。
其主要缺点是:
1)为了使对象可以共享,需要将一些不能共享的状态外部化,这将增加程序的复杂性。
2)读取享元模式的外部状态会使得运行时间稍微变长。
享元模式的结构与实现
享元模式中存在以下两种状态:
1)内部状态,即不会随着环境的改变而改变的可共享部分;
2)外部状态,指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态,并将外部状态外部化。下面来分析其基本结构和实现方法。
(1)模式的结构
享元模式的主要角色有如下:
1)抽象享元(Flyweight)角色:是所有的具体享元类的基类,为具体享元规范需要实现的公共接口,非享元的外部状态以参数的形式通过方法传入。
2)具体享元(Concrete Flyweight)角色:实现抽象享元角色中所规定的接口。
3)非享元(Unsharable Flyweight)角色:是不可以共享的外部状态,它以参数的形式注入具体享元的相关方法中。
4)享元工厂(Flyweight Factory)角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检査系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。
享元模式的应用场景
前面分析了享元模式的结构与特点,下面分析它适用的应用场景。享元模式是通过减少内存中对象的数量来节省内存空间的,所以以下几种情形适合采用享元模式。
1)系统中存在大量相同或相似的对象,这些对象耗费大量的内存资源。
2)大部分的对象可以按照内部状态进行分组,且可将不同部分外部化,这样每一个组只需保存一个内部状态。
3)由于享元模式需要额外维护一个保存享元的数据结构,所以应当在有足够多的享元实例时才值得使用享元模式。
组合模式
在现实生活中,存在很多“部分-整体”的关系,例如,大学中的部门与学院、总公司中的部门与分公司、学习用品中的书与书包、生活用品中的衣月艮与衣柜以及厨房中的锅碗瓢盆等。在软件开发中也是这样,例如,文件系统中的文件与文件夹、窗体程序中的简单控件与容器控件等。对这些简单对象与复合对象的处理,如果用组合模式来实现会很方便。
组合模式的定义与特点
定义: 有时又叫部分-整体模式,他说一种将对象组合成树状的层次结构的模式,用来表示“部分-整体”的关系,使用户对单个对象和组合对象具有一致的访问性。
优点:
- 组合模式使得客户端代码可以一致地处理单个对象和组合对象,无须关心自己处理的是单个对象,还是组合对象,简化了客户端代码
- 更容易在组合体内加入新的对象,客户端不会因为新的对象而更改源代码,满足“开闭原则”
缺点:
- 设计较复杂,需要花更多时间理解类之间的层次关系;
- 不容易限制容器中的构件
- 不容易用继承的方法来增加构件的新功能。
组合模式的结构与实现
- 组合模式的结构
包含以下主要角色:
1) 抽象构件角色:它主要是 作为叶子节点和树枝节点声明的公共接口,并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口;在安全式的组合模式中不声明访问和管理子类的接口,管理工作由树枝结构完成。
2) 树叶构件角色:是组合中的叶子节点对象,它没有子节点,用于实现抽象构件角色中的声明的公共接口。
3) 树枝节点角色:是组合中的树枝节点对象,他有子节点。它实现了抽象构件角色中声明的接口,主要作用是存储和管理子构件,通常有Add,Remove,GetChild等方法。
组合模式分为透明式和安全式
透明式,该方式中,由于抽象构件声明了所有子类中的全部方法,所以客户端无需区别树叶对象和树枝对象,对客户端来说是透明的。但缺点是:树叶构件没有Add,Remove,GetChild方法,却要实现它们(异常或者空实现),这样会带来一些安全性问题。
安全式,该方式中,将管理构件的方法转移到树枝构件中,抽象构件和树叶构件没有对子对象的管理方法,这样就避免了上一种方式上的安全问题,但是由于树叶和分支有不同的接口,客户端在调用的时候需要知道树叶对象和树枝对象的存在,所以失去了透明性。
组合模式的应用场景
前面分析了组合模式的结构与特点,下面分析它适用的以下应用场景。
1)在需要表示一个对象整体与部分的层次结构的场合。
2)要求对用户隐藏组合对象与单个对象的不同,用户可以用统一的接口使用组合结构中的所有对象的场合。