23个软件设计模式

目录

一、设计模式是什么

设计模式的本质是面向对象设计原则的实际运用,是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。

正确使用设计模式具有以下优点。
1. 可以提高程序员的思维能力、编程能力和设计能力。
2. 使程序设计更加标准化、代码编制更加工程化,使软件开发效率大大提高,从而缩短软件的开发周期。
3. 使设计的代码可重用性、可读性强、可靠性高、灵活性好、可维护性强。

设计模式分类

1.创建型模式
用于描述“怎样创建对象”,它的主要特点是“将对象的创建与使用分离”。主要有单例、原型、工厂方法、抽象工厂、创建者等5中创建型模式。
2.结构型模式
用于描述如何将类或对象按某种布局组成更大的结构,主要有代理、适配器、桥接、装饰、外观、享元、组合等7中结构模式。
3.行为型模式
用于描述类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务,以及怎样分配职责。主要有模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等11中行为型模式。

二、UML

类图表示法

类的表示方法

在这里插入图片描述

类与类之间关系的表示方式
关联关系

1、单向关联在这里插入图片描述
2、双向关联
在这里插入图片描述
3、自关联
在这里插入图片描述

聚合关系

在这里插入图片描述
“单体”可以脱离“整体”,继续完成自身的功能

组合关系

在这里插入图片描述
“整体” 不存在 “单体” 也无法存在。

依赖关系

在这里插入图片描述

继承关系

在这里插入图片描述

实现关系

在这里插入图片描述

三、软件设计原则

1、开闭原则

对扩展开放,对修改关闭
在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。
想要达到这样的效果,我们需要使用接口和抽象类。
因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展,但软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以。
事例:
在这里插入图片描述
该“皮肤功能”,通过“AbstractSkin”抽象皮肤的功能,当有新皮肤加入时只需要重新创建一个继承“AbstractSkin”的类就可以,不需要修改以往的代码以及架构。

2、里氏代换原则

里氏代换原则:任何基类可以出现的地方,子类一定可以出现。通俗理解:子类可以扩展父类的功能,但不能改变父类原有的功能。换句话说,子类继承父类时,除添加新的方法完成新增功能外,尽量不要重写父类的方法
如果通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别时运用多态比较频繁时,程序运行出错的概率会非常大。
在这里插入图片描述
在这里插入图片描述
实例描述:可以理解为一个基类/父类的子类由于重写了基类/父类中的方法,导致原来实现的功能模块出现异常。因此尽量不要重写基类/父类的方法。

3、依赖倒转原则

高层模块不应该依赖底层模块,两者都应该依赖其抽象;抽象不应该依赖细节(实现类/子类),细节(实现类/子类)应该依赖抽象。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。(依赖倒转原则其实也是开闭原则的具体实现)
在这里插入图片描述

例子:电脑与CPU、硬盘、内存条

在这里插入图片描述
如果想要更换CPU或者是其他硬件,我们就需要修改Computer里的代码,因为上图中Computer的成员变量是IntelCpu只能使用英特尔的CPU,违背了开闭原则。

解决:对抽象进行编程

在这里插入图片描述

4、接口隔离原则

客户端不应该被迫依赖与它不使用的方法;一个类对另一个类的依赖应该建立在最小的接口上。
在这里插入图片描述

例子:安全门的实现

在这里插入图片描述
如果当我们只想做有防火、防盗的新产品时,因为规范接口里面同时有防火、防盗和防水的功能,所有就会导致我必须实现防水的功能(方法)。

解决:依赖应该建立在最小的接口

在这里插入图片描述

5、迪米特法则

迪米特法则又叫最少知道原则。
如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

例子:

在这里插入图片描述
“明星”、“粉丝”、“媒体公司”三者都能单独运作,当三者因为需求需要合作就需要“经纪人”来作为中间人来负责处理需要的事务,“明星”、“粉丝”、“媒体公司”就根据经济人的需求做自己能做的就可以,不需要具体了解其他人的详细工作流程。

6、合成复合原则

合成复用原则是指:尽量先使用组合或聚合等关联关系来实现,其次才考虑使用继承关系来实现。
通常类的复用分为继承复用和合成复用两种。
继承复用虽然有简单和易实现的优点,但它也存在以下缺点:
1.继承复用破坏了类的封装性。因为继承会间父类的实现细节暴露给子类,父类对子类是透明的,所以这种复用又称为“白箱”复用。
2.子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化,这不利于类的扩展与维护。
3.它限制了复用的灵活性。从父类继承而来的实现是静态的,在编译时以及定义,所以在运行时不可能发生变化。
采用组合或聚合复用时,可以间已有对象纳入新对象中,使之成为新对象的一部分,新对象可以调用已又对象的功能,它有以下优点:
1.它维持了类的封装性。因为成分对象的内部细节是新对象看不见的,所以这种复用又称为“黑箱”复用。
2.对象间的耦合度低。可以在类的成员位置声明抽象。
3.复用的灵活性高。这种复用可以在运行时动态进行,新对象可以动态地引用与成分对象类型相同的对象。

例子:汽车

在这里插入图片描述
如上图:是一个汽车的类结构图,每一个汽车动力源需要一个子类实现,没有一个动力源子类有需要不同的颜色子类来实现才能满足需求。

当添加新的动力源子类:光能汽车
在这里插入图片描述
根据需求我们最少需要添加3个子类才能完成。
在这里插入图片描述
聚合复用可以看到实现总需要的5个类1个接口。

当添加新的动力源子类:光能汽车
在这里插入图片描述
可以看到,当添加新的动力源类型时,在聚合复用只需要添加1个新类即可实现。
所以尽量先使用组合或聚合等关联关系来实现,其次才考虑使用继承关系来实现

四、创建者模式

1、单例设计模式

单例模式是JAVA中最简单的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式,可以直接访问,不需要实例化该类的对象。

单例模式的结构

单例模式的主要有以下角色:

  1. 单例类,只能创建一个实例的类
  2. 访问类,使用单例类
单例模式的实现

单例设计模式分为两种:
饿汉式:类加载就会导致该单例实例对象被创建
懒汉式:类加载不会导致该单例实例对象被创建,而是首次使用该对象时才会创建

饿汉式 - 01 - 静态成员变量
在这里插入图片描述
饿汉式 - 02 - 静态代码块
在这里插入图片描述
对象的创建时在静态代码中,也就是跟随类加载而创建。所以饿汉式的方式创建,当代码逻辑中没有使用到该单例,该单例对象也会一直在内存中占用空间,会导致内存浪费。

饿汉式创建优缺点

  • 优点:创建单例线程安全,因为在类加载中创建不存在线程安全问题。
  • 缺点:内存浪费。

饿汉式 - 03 - 枚举方式
在这里插入图片描述
枚举类实现单例模式时极力推荐的单例实现模式,因为枚举类型时线程安全的,并且只会装载一次,设计者充分的利用了枚举的这个特性来实现单例模式,枚举的写法非常简单,而且枚举类型时所用单例实现中唯一一种不会被破坏的单例实现模式。

懒汉式 - 01
在这里插入图片描述
“getInstance”需要添加synchronized来确保线程安全,不然这种实现方式在多线程的情况会导致该单例创建两个实例。

懒汉式优缺点

  • 优点:在不使用该单例的情况不会创建实例,不会占据内存空间。
  • 缺点:为了确保线程安全需要添加**synchronized*保证方法同步,会导致方法执行有线程阻塞,在多线程情况会有一定耗时。

懒汉式 - 02 - 双重检查锁方式
对于getInstance绝大部分得操作都是读操作,读操作时线程安全的,所以我们没必要让每个线程必须持有锁才能调用该方法,需要调整加锁的时机。改良之后就是双重检查锁模式
在这里插入图片描述
双重检查锁其实也存在问题,在多线程的情况下,可能会出现空指针问题,出现问题的原因是JVM在实力化对象的时候会进行优化指令重排序操作。要解决双重检查锁模式带来的问题,只需要使用volatile关键字,该关键字可以保证可见性和有序性。
在这里插入图片描述
添加volatile关键字之后的双重检查锁模式是一种比较好的单例实现模式,能够保证在多线程的情况下线程安全也不会有性能问题。

懒汉式 - 03 - 静态内部类
静态内部类单例模式中实例有内部类创建,由于JVM在加载外部类的过程中,是不会加载静态内部类的,只有内部类的属性/方法被调用时才会被加载,并初始化其静态属性。静态属性由于被static修饰,保证只被实力化一次。并且严格保证实力化顺序。
在这里插入图片描述
静态内部类单例模式时一种优秀的单例模式,时开源项目中比较常用的一种单例模式。在灭有加任何锁的情况下,保证了多线程下的安全,并且没有任何性能影响和空间的浪费。

破坏单例模式

使单例类可以创建多个对象,枚举方式除外。

1、序列化反序列化
第一步:将类序列化输出
将单例类实现Serializable序列化接口
在这里插入图片描述
将单例类序列化并输出成File
在这里插入图片描述
第二步:反序列化创建对象
在这里插入图片描述
每当调用反序列化时,系统都会创建一个新的对象。这就导致单例类不再是单例了

2、反射
在这里插入图片描述
通过反射创建多次单例。

1、序列化反序列化 - 解决办法
在单例类中添加**readResolve()方法,在反序列化时被反射调用,如果定义了这个方法,就返回这个方法的指,如果没有定义,则返回新new出来的对象。
在这里插入图片描述
可以看
ObjectInputStream#readObject()**方法
在这里插入图片描述

2、反射 - 解决办法
在这里插入图片描述
不然该单例类重复调用构造方法。

JDK源码中的单例模式

Runtime

2、工厂模式

需求:设计一个咖啡店点餐系统。
在这里插入图片描述
核心类CoffeeStore具体实现
在这里插入图片描述
假如我们需要更换对象,所有的咖啡对象new的地方都需要修改,这违背了软件设计的开闭原则。如果我们使用工厂来生产对象,我们就只和工厂打交道就可以了,咖啡店彻底和对象解耦。所以说工厂模式最大的优点就是:解耦

简单工厂模式

将 new 咖啡的逻辑解耦提取
在这里插入图片描述
这样咖啡店就与咖啡解耦了
在这里插入图片描述
简单工厂模式,优缺点:
优点:
封装了创建对象的过程,可以通过参数直接获取对象。把对象的创建和业务逻辑层分开,这样以后就避免了修改客户代码,如果要实现新产品直接修改工程类,而不需要在原代码中修改,这样就降低了客户段代码修改的可能性,更加容易扩展。
缺点:
增加新产品时还是需要修改工厂类的代码,违背了“开闭原则”。

静态工厂
在这里插入图片描述

工厂方法模式

针对上例中的缺点,使用工厂方法模式就可以完美的解决,完全遵循开闭原则。

概念
定义一个用于创建对象的接口,让子类决定实力化那个产品类对象,工厂方法使一个产品类的实例化延迟到其工厂的子类。

结构

  • 抽象工厂:提供了产品的接口,调用者通过它访问具体工厂的工厂方法类创建产品。
  • 具体工厂:主要是实现抽象工厂中的抽象方法,完成具体产品的创建。
  • 抽象产品:定义了产品的规范,描述了产品的主要特性和功能。
  • 具体产品:实现了抽象产品角色所定义的接口,有具体工厂来成员将,它同具体工厂之间一一对应。

实现
在这里插入图片描述
咖啡店使用抽象工厂,这样在新增咖啡时就可以通过新增工厂咖啡来实现,旧的代码类不需要修改,满足开闭原则

工厂方法优缺点:
优点:
1.用户只需要知道具体工厂的名称就可得到所需要的产品,无须知道产品的具体创建过程;
2.在系统增加新的产品时只需要添加具体产品类和队友的具体工厂类,无须对原工厂进行任何修改,满足开闭原则。

缺点:
1.每增加一个产品就要增加一个具体产品类和一个对于的具体工厂类,这增加了系统的复杂度。

抽象工厂模式

概念
是一种为访问类提供一个创建一组相关相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族不同等级的产品模式结构。
抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品。

结构

  • 抽象工厂:提供创建产品的接口,它包含多个创建产品的方法,可以创建多个不同等级的产品。
  • 具体工厂:主要是实现抽象工厂中的多个抽象方法,完成具体产品的创建。
  • 抽象产品:定义了产品的规范,描述了产品的主要特性和功能,抽象工厂模式有多个抽象产品。
  • 具体产品:实现了抽象产品角色所定义的接口,有具体工厂来创建,它同具体工厂之间是多对一的关系。

实现
在这里插入图片描述
由图可以看到,通过抽象工厂模式,可以实现生产同类型,不同族的产品,也就是说如果有新的咖啡新增这个咖啡必须是新的族,也就需要添加新的咖啡类和新的工厂类,之后如果新增了与新咖啡相同族新的提拉米苏就不需要新增工厂

所以在抽象工厂模式,每一个新增的同类型产品,与工厂方法模式一样需要新增新产品类以及新工厂类,只是优化了新增不同产品的情况。

抽象工厂模式,优缺点

优点:
当**一个产品族(咖啡同级)**中的多个对象被设计一起工作时,它能保证客户端始终只使用同一个产品族中的工厂对象。

缺点:
产品族(咖啡同级)中需要新增一个新的产品时,所有的工厂类都需要进行修改(新增新产品的生产方法)。

简单工厂模式 + 配置文件解除耦合

可以通过工厂模式+配置文件的方式解除工厂对象和产品对象的耦合,在工厂类中加载配置文件中的全类名,并创建对象进行存储,客户端如果需要对象,直接进行获取即可。

第一步:定义配置文件
在这里插入图片描述
第二步:改进工厂类
通过读取配置文件,以及反射来创建产品对象
在这里插入图片描述
创建对象时,通过传入配置文件中的产品名称来返回对应的对象
在这里插入图片描述
该例子可以看出,当有新增产品的时候就不需要修改工厂类和产品类(不需要修改原来的代码),只需要新增一个产品类并且将新增产品添加到配置文件中就可以。实现了工厂类与产品类的解耦

JDK源码中的工厂模式

Collection.iterator

3、原型模式

概述

用一个以及创建的实例作为原型,通过复制该原型对象来创建一个和原型对象相同的新对象。

结构

原型模式包含如下角色:

  • 抽象原型类:规定了具体原型对象必须实现的clone() 方法。
  • 具体原型类:实现抽象原型类的 clone() 方法,它是可被复制的对象。
  • 访问类:使用具体原型类中的 clone() 方法来复制新的对象。

在这里插入图片描述

实现

原型模式的克隆分为浅克隆深克隆

**浅克隆:**创建一个新对象,新对象的属性和原来对象完全相同,对于非基本类型属性,仍指向原有属性所指向的对象的内存地址。

**深克隆:**创建一个新对象,属性中引用的其他对象也会被克隆,不再指向原有对象地址。

Realizetype对象实现Cloneable,并且重写clone()方法。
在这里插入图片描述
这个原型复制是
浅克隆
,因为创建一个新对象,新对象的属性和原来对象完全相同,对于非基本类型属性,仍指向原有属性所指向的对象的内存地址。所有两个对象是不同的,但是里面的非基础类型属性的内存地址是相同的
在这里插入图片描述

案例

在这里插入图片描述
在这里插入图片描述

使用场景
  • 对象的创建非常复杂,可以使用原型模式快捷的创建对象。
  • 性能和安全要求比较高。(如创建一个能克隆的对象,之后还需要该对象就直接复制就不需要new了)。

疑问:new与clone有什么区别?

深克隆

以上说的实现与案例都是浅克隆,如果想实现深克隆(也就是两个对象内的属性都各自有各自的内存空间,不相互影响),可以通过序列化与反序列来实现。
在这里插入图片描述

4、创建者模式

概述

将一个复杂对象的构建与表示分离,使得同样的构建过程(创建步骤)可以创建不同的表示(不同的实例对象)。

结构

建造者模式包含如下角色:

  • 抽象建造者类:这个接口规定要实现复杂对象的那些部分的创建,并不涉及具体的部件对象的创建。
  • 具体建造者类:实现Builder接口,完成复杂产品的各个部件的具体创建方法。在构造过程完成后,提供产品的实例。
  • 产品类:要创建的复杂对象。
  • 指挥者:调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。

在这里插入图片描述

实例

在这里插入图片描述
在这里插入图片描述
声明产品类时就new了产品createBike多次调用返回都是同一个类。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在主程序,构建产品时,主程序并不需要知道具体的产品构建过程。

优缺点

在这里插入图片描述

使用场景
  • 创建对象较为复杂的时候,各各**部件(类成员)**创建复杂变化多样,但是构建顺序过程是不变的。
  • 创建复杂对象的过程与其组件(类成员)相互独立
模式扩展

在一些对象构建需要大量的属性传入时。

在这里插入图片描述

当我们去实例化这个类时,代码可读性会很低,代码写起来也很冗长。

在这里插入图片描述
改造Phone类

public class Phone{
	private String cpu;
	private String screen;
	private String memory;
	private String mainboard;
	
	// 私有了Phone构造方法。
	private Phone(Builder builder){
		this.cpu = builder.cpu;
		this.screen= builder.screen;
		this.memory= builder.memory;
		this.mainboard= builder.mainboard;
	}

	//set 与 get方法这里就省略了
	
	public static final class Builder{
		private String cpu;
		private String screen;
		private String memory;
		private String mainboard;
		
		public Builder cpu(String cpu){
			this.cpu = cpu;
		}
		public Builder screen(String screen){
			this.screen= screen;
		}
		public Builder memory(String memory){
			this.memory= memory;
		}
		public Builder mainboard(String mainboard){
			this.mainboard= mainboard;
		}
		
		// 同内部类去访问Phone的构造方法,并返回给调用者
		public Phone build(){
			return new Phone(this)
		}
	}
}

改造完了之后,使用起来。

在这里插入图片描述
可以看到代码一目了然,并且用链式结构编码,后续有新增成员变量也方便修改。

五、结构型模式

1、代理模式

概述

由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时,访问对象不适合或者不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介。
JAVA中的代理安装代理类生成时机不同又分为静态代理和动态代理。静态代理代理类在编译期就生成,而动态代理代理类则是在JAVA运行时动态生成,动态代理又JDK代理和CGLIB代理两种。

结构

代理模式分为三种角色:

  • 抽象主题类: 通过接口或抽象类声明真实主题和代理对象实现的业务方法。
  • 真实主题类: 实现了抽象主题中的具体业务,时代理对象所代表的真实对象,时最终要引用的对象。
  • 代理类: 提供了真实主题相同的接口,其内部含有对真实主题的引用,它可以访问,控制或扩展真实主题的功能。
静态代理

静态代理代理类在编译期就生成
在这里插入图片描述
在这里插入图片描述
代理类真实主题类都要实现抽象主题类

动态代理

动态代理代理类则是在JAVA运行时动态生成
有点像匿名内部类,动态代理的代理类具体的java文件。
在这里插入图片描述

cglib代理

在这里插入图片描述
真实主题类没有抽象主题接口时可以通过cglib来实现代理。
在这里插入图片描述
在这里插入图片描述

三种代理对比

在这里插入图片描述

优缺点

优点

  • 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用。
  • 代理对象可以扩展目标对象的功能。
  • 代理模式能将客户端与目标对象分离,在一定程度上降低了系统的耦合度。

缺点

  • 增加了系统的复杂度
使用场景

在这里插入图片描述

2、适配器模式

概述

简单理解为转接口,如将一个Type-C的USB数据线,通过转接口转换为苹果设备的数据接口

定义:
将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
适配器模式分为类适配器模式和对象适配器模式,前者类之间的耦合度比后者高,且要求程序员了解现有组件库中的相关组件的内部结构,所有引用相对较少。

结构

目标接口:当前系统业务所期待的接口,它可以时抽象类或接口。
适配者类:它是被访问和适配的现存组件库中的组件接口。
适配器类:它是一个转换器,通过继承或引用适配者的对象,把适配者接口转换成目标接口,让客户按目标接口的格式访问适配者。

类适配器模式 - 1

实现方式:定义一个适配器类来实现当前系统的业务接口,同时又继承现有组件库中以及存在的组件。
在这里插入图片描述
主程序,读取SD卡与TF卡中的数据
在这里插入图片描述
在这里插入图片描述
1、通过继承适配者来调用适配者的方法。
2、通过实现目标接口来让适配器类可以当作目标实例来使用。

类适配器模式问题

1、类适配器模式违背了合成复用原则。少用继承多用组合与聚合
2、类适配器是客户类有一个接口规范的情况下可用,反之不可用。没有目标的接口,就没有办法实现

对象适配器模式 - 2

在这里插入图片描述

满足合成复用原则,少用继承多用组合于聚合

在这里插入图片描述
在这里插入图片描述

通过聚合降低了适配器类适配者类之间的耦合度。

接口适配器模式 - 3

不希望实现一个接口中所有的方法时,可以创建一个抽象类,实现所有方法,而此时我们只需要继承该抽象类,重写我们只需要的方法即可。

应用场景
  • 以前开发的系统存在满足新系统功能需求的类,但其接口同新系统的接口不一致。
  • 使用第三方提供的组件,但组件接口定义和自己要求的接口定义不同。
适配器模式在JDK源码中的运用

IO流中的使用,该图中有两对适配者模式。
在这里插入图片描述

3、装饰者模式

概述

例子:
快餐点有炒面、炒饭。可以额外附加鸡蛋、火腿、培根这些配菜,当然加配菜需要额外加钱,每个配菜的价钱通常不太一样,那计算总价就会比较麻烦。
在这里插入图片描述
假设,追加配料“培根”,需要添加两个新类
在这里插入图片描述
假设,在添加一个新品“炒河粉”,需要新增四个类。
在这里插入图片描述
如果使用继承的方式,扩展性不好(新增一个配料需要修改之前的代码),导致类爆炸(在配料太多的情况新增产品需要创建很多的子类)。

定义

指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(新增额外功能)的模式。

结构
  • 抽象构件角色:定义一个抽象接口以规范准备接收附加责任的对象。
  • 具体构件角色:实现抽象构件,通过装饰角色为器添加新功能。
  • 抽象装饰角色:继承或实现抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能。
  • 具体装饰角色:实现抽象装饰的相关方法,并给具体构件对象添加附加功能。
案例

还是上的快餐案例
在这里插入图片描述

装饰者类
在这里插入图片描述

具体装饰类 - 鸡蛋
在这里插入图片描述

主程序的使用
在这里插入图片描述

输出结果:
在这里插入图片描述

优缺点

在这里插入图片描述

使用场景
  • 不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。
    不能采用继承的情况主要有两种:
    1. 系统中安存在大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目爆炸增长。
    2. 以你为类定义不能继承,如 final 类。
  • 在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责
  • 当对象在功能要求可以动态地添加,也可以再动态地撤销时。
装饰者模式在JDK中的使用

IO流中的保证类,BufferedInputStream、BufferedOutputStream、BufferedReader、BufferedWriter。
在这里插入图片描述

静态代理和装饰者模式的区别

相同点:

  • 都要实现与目标类相同的业务接口
  • 在两个类中都要声明目标对象
  • 都可以在不修改目标类的前提下增强目标方法

不同点:

  • 目的不同,装饰者是为了增持目标对象,静态代理是为了保护和隐藏目标对象
  • 获取目标对象构建的地方不同,装饰者是由外界传递进来,可以通过构造方法传递,静态代理是在代理类内部创建,以此来隐藏目标对象。

3、桥接模式

概述

在这里插入图片描述

结构

抽象化角色:定义抽象类,并包含一个对实现化对象的引用。
扩展抽象化角色:是抽象化角色的子类,实现父类中的业务方法,并通过组合关系调用实现化角色中的业务方法。
实现化角色:定义实现化角色的接口,供扩展抽象化角色调用。
具体实现化角色:给出实现化角色接口的具体实现。

案例

在这里插入图片描述

好处
  • 桥接模式提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统。
  • 实现细节对客户透明
使用场景
  • 当一个类存在两个独立变化的维度,且这两个维度都需要进行扩展时。
  • 当一个系统不希望使用继承因为多层次继承导致系统类的个数急剧增加时。
  • 当一个系统需要在构建的抽象化角色和具体化角色之间增加更多的灵活性时。避免在两个层次之间建立静态的继承联系,通过桥接模式可以使它们在抽象层建立一个关联关系。

4、外观模式

概述

在这里插入图片描述

结构

外观角色:多为个子系统对外提供一个共同的接口。
子系统角色:实现系统的部分功能,客户可以通过外观角色访问它。

案例

在这里插入图片描述

优缺点

好处:

  • 降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类。
  • 对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易
    缺点:
  • 不符合开闭原则,修改很麻烦
使用场景
  • 分层结构系统构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
  • 当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问。
  • 当客户端与多个子系统之间存在很大的联系时,引入外观模式可将它们分离,从而提高子系统的独立性和可移植性
源码实例

tomcat - RequestFacade
在这里插入图片描述
外观模式?我怎么看着像静态代理?

5、组合模式

概述

在这里插入图片描述
定义:又名部分整体模式,是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象,用来表示部分以及整体层次。这种类型的设计模式属于结构模式,它创建了对象组的树形结构。

结构
  • 抽象根节点:定义系统各层次对象的共有方法和属性,可以预先定义一些默认行为和属性。
  • 树枝节点:定义树枝节点的行为,存储子节点,组合树枝节点和叶子节点形成一个树形结构。
  • 叶子节点:叶子节点对象,其下再无分支,是系统层次遍历的最小单位。
案例 - 透明组合模式 - 1

在这里插入图片描述
在这里插入图片描述
抽象根节点对象
在这里插入图片描述

树枝节点对象
继承 -> 抽象根节点对象
在这里插入图片描述

叶子节点对象
继承 -> 抽象根节点对象
在这里插入图片描述

透明组合模式总结:
在这里插入图片描述

组合模式分类 - 安全组合模式 - 2

在这里插入图片描述

优点

在这里插入图片描述

使用场景

组合模式正是因树形结构而生,所有组合模式的使用场景就是出现树形结构的地方,比如:文件目录显示,多级目录呈现等树形结构数据的操作。

6、享元模式

概述

运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似对象的开销,从而提高系统资源的利用率

结构

享元模式中存在以下两种状态:
1、内部状态,即不会随着环境的改变而改变的可共享部分。
2、外部状态,指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的者两种状态,并将外部状态外部化。
享元模式的主要有以下角色:

  • 抽象享元角色:通常是一个接口或抽象类,在抽象享元类中声明了具体享元类公共的方法,这些方法可以向外界提供享元对象的内部数据(内部状态),同时也可以通过这些方法来设置外部数据(外部状态)。
  • 具体享元角色:它实现了抽象享元类,称为享元对象;在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类,为每一个具体享元类提供唯一的享元对象。
  • 非享元角色:并不是所有的抽象享元类的子类都行被共享,不能被共享的子类可以设计为非共享具体享元类;当需要一个非共享具体享元类的对象可以直接实力化创建。
  • 享元工厂角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检查系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。
案例实现

在这里插入图片描述

类图
在这里插入图片描述
其中的具体享元角色,可以是单例。

下图是享元工厂角色
在这里插入图片描述

优缺点 和 使用场景

1、优点:

  • 极大减少内存中相似或相同的对象数量,节约系统资源,提供系统性能
  • 享元模式中的外部状态相对独立(相对具体享元类实例相互独立),且不影响内部状态。

2、缺点:
为了使对象可以共享,需要将享元对象的部分状态外部化,分离内部状态和外部状态,使程序逻辑复杂

3、使用场景:

  • 一个系统有大量相同或者相似的对象,造成内存的大量消耗
  • 对象的大部分状态都可以外部化,可以将这些外部状态传入对象中。
  • 在使用享元模式时需要维护一个存储享元对象的享元池,而这需要消耗一定的系统资源,因此,应当在需要多次充分使用享元对象时才值得使用享元模式。
JDK源码

Integer类使用了享元模式。

六、行为型模式

行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法独立完成的任务,它涉及算法与对象间职责的分配。

行为型模式分为类行为模式对象行为模式前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所有对象行为模式比类行为模式具有更大的灵活性。

1、模板方法模式

概述

在这里插入图片描述
定义
定义一个操作中的算法骨架,而将算法的一些步骤延迟到子类中,使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

结构

抽象类:负责给出一个算法的轮廓和骨架,它由一个模板方法和若干各基本方法构成。

  • 模板方法:定义了算法的骨架,按某中顺序调用其包含的基本方法。
  • 基本方法:是实现算法各个步骤的方法,是模板方法的组成部分。基本方法由可以分为三种。
    • 抽象方法:一个抽象方法由抽象类声明,由其具体子类实现。
    • 具体方法:一个具体方法由一个抽象类或具体类声明并实现,其子类可以进行覆盖也可以直接继承。
    • 钩子方法:在抽象类中已经实现,包括用于判断的逻辑方法和需要子类重写的空方法两种。一般钩子方法是用与判断的逻辑方法,这类方法名一般为isXXXX,返回值类型为boolen类型。

具体子类:实现抽象类中所定义的抽象方法和钩子方法,它们是一个顶级逻辑的组成步骤。

案例

炒菜:
炒菜的步骤是固定的,分为倒油、热油、倒蔬菜、倒调料品、翻炒等步骤。
在这里插入图片描述

炒菜抽象类具体实现:
在这里插入图片描述

具体的炒菜类实现:
在这里插入图片描述

优缺点

优点:

  • 提供代码复用性,将相同部分的代码放在抽象的父类中,而将不同的代码放入不同的子类中。
  • 实现了反转控制,通过一个父类调用其子类的操作,通过对子类的具体实现扩展不同的行为,实现了反向控制,并符合”开闭原则“。

缺点:

  • 对每个不同的实现都需要定义一个子类,这会导致类的个数增加,系统更加庞大,设计也更加抽象。
  • 父类中的抽象方法由子类实现,子类执行的结果会影响父类的结果,这会导致一种反向控制结构,它提高了代码阅读的难度。
适用场景
  • 算法的整体步骤很固定,但其中个别部分易变时,这时候可以使用模板方法模式,将容易变得部分抽象出来,供子类实现。
  • 需要通过子类来决定父类算法中某个步骤是否执行,实现子类对父类得反向控制。
JDK源码中的使用

InputStrem类
在这里插入图片描述

2、策略模式

概述

在这里插入图片描述
定义:
该模式定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式,它通过对算法进行封装,把使用算法的责任和算法的实现分割开来,并委派给不同的对象对这些算法进行管理

结构
  • 抽象策略类:这是一个抽象角色,通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口
  • 具体策略类实现了抽象策略定义的接口,提供具体的算法实现或行为。
  • 环境类持有一个策略类的引用,最终给客户端调用。
案例实现

在这里插入图片描述
代码没有什么特别的,就环境类直接调用抽象策略类的接口就可以,不需要知道具体策略类的具体实现细节。

优缺点:

优点

  • 策略之间可以自由切换,由于策略类都实现同一个接口,所以使它们之间可以自由切换。
  • 易于扩展,增加一个新的策略只需要添加一个具体的策略类即可,基本不需要改变原有的代码,符合“开闭原则”。
  • 避免使用多重条件选择语句,充分体现面向对象设计思想。

缺点

  • 客户端必须知道所有的策略类,并自行决定使用那个策略类。
  • 策略模式将造成很多策略类,可以通过使用享元模式在一定程度上减少对象的数量。
使用场景
  • 一个系统需要动态地在几种算法中选择一种时,可将每个算法封装到策略类中。
  • 一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现,可将每个条件分支移入它们各自的策略类中以代替这些条件语句。
  • 系统中各算法彼此完全独立,且要求对客户隐藏具体算法的实现细节时。
  • 系统要求使用算法的客户不应该知道其操作的数据时,可使用策略模式来隐藏与算法相关的数据结构。
JDK源码的运用

Comparator在Array排序中的使用

3、命令模式

概述

定义:
将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将名利对象进行存储、传递、调用、增加与管理。

结构
  • 抽象命令:定义命令的接口,声明执行的方法。
  • 具体命令:具体的命令,实现命令接口;通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
  • 实现者/接收者:接收者,真正执行命令的对象。任何类都可能称为一个接收者,只要它能够实现命令要求实现的相应功能。
  • 调用者/请求者:要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
实例

在这里插入图片描述

请求者类:
在这里插入图片描述

具体命令类:
在这里插入图片描述

抽象命令类:
就一个 execute() 抽象方法。

优缺点

优点:

  • 降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
  • 增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类,它满足“开闭原则”,对扩展比较灵活。
  • 可以实现宏命令,命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。
  • 方便实现Undo和Redo操作。命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。

缺点:

  • 使用命令模式可能会导致某些系统有过多的具体命令类。
  • 系统结构更加复杂。
使用场景
  • 系统需要将请求调用者和请求接收者解耦,使得调用者和接收者不能直接交互。
  • 系统需要在不同的时间指定请求,将请求排队和执行请求。
  • 系统需要支持命令的撤销操作和恢复操作。
JDK源码中的使用

Runable - 抽象命令类,run抽象方法
Thread - 请求者
Runable实例 - 具体命令类
Runable实例的执行内容 - 接收者

4、责任链模式

概述

定义:
又名责任链模式,为了避免请求发送者与多个请求处理者耦合在一起,将所有请求的处理者通过前一对象记住其下一各对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到对象处理它为止。

结构
  • 抽象处理者:定义一个处理请求的接口,包含抽象处理方法和一个后继连接
  • 具体处理者:实现抽象处理者的处理方法,判断能否处理本次请求,如果可以处理请求到处理,否则将该请求转给它的后继者
  • 客户类:创建处理链,并向链头的具体处理者对象提交请求,它不关心处理细节和请求的传递过程
案例

在这里插入图片描述

抽象处理者
在这里插入图片描述

具体处理者 - 小组长
在这里插入图片描述

具体处理者 - 部门经理
在这里插入图片描述

具体处理者 - 总经理
在这里插入图片描述

优缺点

在这里插入图片描述
在这里插入图片描述

JDK源码实现

FileterChain类,网络请求过滤器

5、状态模式

概述

案例
在这里插入图片描述
具体实现类
在这里插入图片描述
可以看出这样的方式,在添加新的状态或者“操作”都需要对象该实现类进行大量的改动。

定义
对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。

结构

环境角色:也称为上下文,它定义了客户程序需要的接口,维护一个当前状态,并将与状态相关的操作委托给当前状态对象来处理
抽象状态角色:定义一个接口,用以封装环境对象中的特定状态所对应的行为。
具体状态角色:实现抽象状态所对应的行为。

案例实现

在这里插入图片描述

环境对象
在这里插入图片描述

开启状态 - 实现类
在这里插入图片描述

优缺点

在这里插入图片描述

使用场景

在这里插入图片描述

6、观察者模式

概述

定义
又被称为发布-订阅模式,它定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时,会通知所有的观察者对象,使它们能够自动更新自己。

结构

抽象主题类:抽象主题角色把所有观察者对象保存在一个集合里,每个主题都可以有任意数量的观察者,抽象主题提供一个接口,可以增加和删除观察者对象。
具体主题,该角色将有关状态存入具体观察者对象,在具体主题的内部状态发生改变时,给所有注册过的观察者发送通知。
抽象观察者,是观察者的抽象类,它定义了一个更新接口,使得在得到主题更改通知时更新自己。
具体观察者,实现抽象观察者定义的更新接口,以便在得到主题更改通知时更新自身的状态。

案例

在这里插入图片描述

具体主题类
在这里插入图片描述

优缺点

优点

  • 降低了目标与观察者之间的耦合关系,两者之间是抽象耦合关系
  • 被观察者发送通知,所有注册的观察者都会收到信息

缺点

  • 如果观察者非常多的话,那么所有的观察者收到被观察者发送的通知会耗时
  • 如果被观察者有循环依赖的话,那么被观察者发送通知会使观察者循环调用,会导致系统崩溃。
使用场景
  • 对象间存在一对多关系,一个对象的状态发生改变会影响其他对象。
  • 当一个抽象模型有两个方面,其中一个方面依赖于另一个方面时。
JDK源码中的使用

Observable类和Observer类

7、中介者模式

概述

在这里插入图片描述

定义
又叫调停模式,定义一个中介角色来封装一系列对象之间的交互,使原有对象之间的耦合松散,且可以独立地改变它们之间的交互。

结构

抽象中介者:它是中介者的接口,提供了同事对象注册于转发同事对象信息的抽象方法。
具体中介者:实现中介者接口,定义一个List来管理同事对象,协调各个同事角色之间的交互关系,因此它依赖于同事角色。
抽象同事类:定义同事类的接口,保存中介者对象,提供同事对象交互的抽象方法,实现所有相互影响的同事类的公共功能。
具体同事类:时抽象同事类的实现者,当需要于其他同事对象交互时,由中介者对象负责后续的交互

案例

”同事类“通过”中介者“类,实习解耦。
在这里插入图片描述

具体中介类
在这里插入图片描述
在这里插入图片描述

具体同事类 - 租房者
在这里插入图片描述

主程序
在这里插入图片描述

优缺点

在这里插入图片描述

使用场景
  • 系统中对象之间存在复杂的引用关系,系统结构混乱且难以理解。
  • 当想创建一个运行于多个类之间的对象,又不想生成性的子类时。

8、迭代器模式

概述

定义
提供一个对象来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。

结构
  • 抽象聚合:定义存储、添加、删除聚合元素以及创建迭代器对象的接口。
  • 具体聚合:实现抽象聚合类,返回一个具体迭代器的实例。
  • 抽象迭代器:定义访问和遍历聚合元素的接口,通常包含hasNext()、next()等方法。
  • 聚合迭代器:实现抽象迭代器接口中所定义的方法,完成对聚合对象的遍历,记录遍历的当前位置。
案例

在这里插入图片描述

具体聚合类
在这里插入图片描述

具体迭代器类
在这里插入图片描述

主程序
在这里插入图片描述

优缺点

优点:

  • 它支持以不同的方式遍历一个聚合对象,在同一个聚合对象上可以定义多种遍历方式。在迭代器模式中只需要用一个不同的迭代器来替换原有迭代器即可改变遍历算法,我们也可以自己定义迭代器的子类以支持新的遍历方式。
  • 迭代器简化了聚合类,由于引入了迭代器,在原有的聚合对象中不需要再自行提供数据遍历等方法,这样可以简化聚合类的设计
  • 再迭代器模式中,由于引入了抽象层,增加新的聚合类和迭代器类都很方便,无须修改原有代码,满足“开闭原则”的要求。

缺点:

  • 增加了类的个数,这在一定程度上增加了系统的复杂性。
使用场景
  • 但需要为聚合对象提供多种遍历方式时。
  • 但需要为遍历不同的聚合结构提供一个统一的接口时。
  • 当访问一个聚合对象的内容而无须暴露其内部细节的表示时。
JDK中的使用

ArrayList类
在这里插入图片描述

9、访问者模式

定义
封装一些作用于某种数据结构中的各元素的操作,它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作

结构

抽象访问者:定义了对每个元素访问的行为,它的参数就是可以访问的元素,它的方法个数理论上来将与元素类个数是一样的,从这点不难看出,访问者模式要求元素类的个数不能改变。
具体访问者:给出对每一个元素类访问时所产生的具体行为。
抽象元素:提供接受访问方法的具体实现,而这个具体的实现,通常情况下是使用访问者提供的访问该元素类的方法。
对象结构:定义当中所提到的对象结构,对象结构是一个抽象表述,具体点可以理解为一个具有容器性质或者复合对象特性的类,它会含有一组元素,并且可以迭代这些元素,供访问者访问。

案例

在这里插入图片描述

具体元素类
在这里插入图片描述
这里直接传递具体元素类,是因为元素类作为数据,不需要做任何的逻辑处理。

具体访问者
在这里插入图片描述
为什么不只传需要数据,因为元素类做为数据,不应该做逻辑操作,所有的业务逻辑都由访问者类来处理。

对象结构类
在这里插入图片描述
对象结构类,没有什么特别的地方,就是用来管理元素和访问者的

主程序
在这里插入图片描述
目的不在于解耦“访问者”和“元素”,而是将所有的业务逻辑都放置于“访问者”方便后续的扩展

优缺点

在这里插入图片描述

使用场景
  • 对象结构相对稳定,但其操作算法经常变化的程序。
  • 对象结构中的对象需要提供多中不同且不相关的操作,而且要避免让这些操作的变化影响对象的结构。
扩展

1、分派
变量被声明的类型叫做变量的静态类型,有些如又把静态类型叫做明显类型;而变量所引用的对象的真实类型又叫做变量的实际类型。比如 Map map = new HashMap(),map变量的静态类型是Map,实际类型是HashMap,根据对象的类型而对方进行的选择,就是分派。分派又分为两种,即静态分派和动态分派。

静态分派翻身在编译时期,分派根据静态类型信息发生,静态分派对于我们来说并不陌生,方法重载就是静态分派。
动态分派发生在运行时期,动态分派动态地置换掉某个方法。Java通过方法的重写支持动态分派。

2、动态分派:

public class Animal{
	public void execute(){
		System.out.println("Animal");
	}
}

public class Dog extends Animal{
	public void execute(){
		System.out.prinln("dog");
	}
}

public class Cat extends Animal{
	public void execute(){
		System.out.prinln("cat");
	}
}

public class Client{
	public static void main(String[] args){
		Animal a = new Dog();
		a.execute();
		
		Animal a1 = new Cat();
		a1.execute();
	}
}

Java编译器在编译时期并不总是知道那些代码会被执行,因为编译器仅仅知道对象的静态类型,而不知道对象的真实类型;而方法的调用则是根据对象的真实类型,而不是静态类型

3、静态分派

public class Animal{
}

public class Dog extends Animal{
}

public class Cat extends Animal{
}

public class Exectue{
	public void exectue(Animal a){
		System.out.println("Animal");
	}
	public void exectue(Dog d){
		System.out.println("dog");
	}
	public void exectue(Cat c){
		System.out.println("cat");
	}
}

public class Client{
	public static void main(String[] args){
		Animal a = new Animal ();
		Animal a1 = new Dog();
		Animal a2 = new Cat();
		
		Execute exe = new Execute();
		exe.execute(a); // 输出结果 animal
		exe.execute(a1); // 输出结果 animal
		exe.execute(a2); // 输出结果 animal
	}
}

重载方法的分派是根据静态类型进行的,这个分派过程在编译时期就完成了。

4、双分派

public class Animal{
	public void accept(Execute exe){
		exe.execute(this);
	}
}

public class Dog extends Animal{
	public void accept(Execute exe){
		exe.execute(this);
	}
}

public class Cat extends Animal{
	public void accept(Execute exe){
		exe.execute(this);
	}
}

public class Exectue{
	public void exectue(Animal a){
		System.out.println("Animal");
	}
	public void exectue(Dog d){
		System.out.println("dog");
	}
	public void exectue(Cat c){
		System.out.println("cat");
	}
}

public class Client{
	public static void main(String[] args){
		Animal a = new Animal ();
		Animal a1 = new Dog();
		Animal a2 = new Cat();
		
		Execute exe = new Execute();
		exe.execute(a); // 输出结果 animal
		exe.execute(a1); // 输出结果 dog
		exe.execute(a2); // 输出结果 cat
	}
}

在上面代码中,客户端将Execute对象作为参数传递给Animal类型的变量调用的方法,这里完成第一次分派,这里是方法重写,所以是动态分派,也就是执行实际类型中的方法,同时也给自己this作为参数传递进去,这里就完成了第二次分派,这里的Execute类中有多个重载的方法,而传递进行的是this,就是具体的实际类型的对象

双分派实现动态绑定的本质,就是在重载方法委派的前面加上了继承体系中覆盖的环节,由于覆盖是动态的,所以重载就是动态的了。

10、备忘录模式

概述

定义:
又叫快照模式,在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,以便以后当需要时能将该对象恢复到原先保存的状态。

结构
  • 发起人:记录当前时刻的内部状态信息,提供创建备忘录和回复备忘录数据的功能,实现其他业务功能,它可以访问备忘录里的所有信息。

  • 备忘录:负责存储发起人的内部状态,在需要的时候提供这些内部状态发起人。

  • 管理者:对备忘录进行管理,提供保存与获取备忘录的功能,但其不能对备忘录的内容进行访问与修改

  • 备忘录有两个等效的接口:

  • 窄接口:管理者对象(和其他发起人对象之外的任何对象)看到的是备忘录的窄接口,这个窄接口只允许他把备忘录对象传给其他的对象

  • 宽接口:与管理者看到的窄接口相反,发起人对象可以看到一个宽接口,这个宽接口允许它读取所有的数据,以便根据这些数据恢复这个发起人对象的内部状态。

案例

游戏挑战Boss
游戏中的某个场景,游戏角色有生命力、攻击力、防御力等数据,在打Boss前和后一定会不一样的,我们允许玩家如果感觉与Boss决斗的效果不理想可以让游戏恢复到决斗之前的状态。

实现有两种方式:
1、白箱备忘录模式
2、黑箱备忘录模式

白箱备忘录模式
在这里插入图片描述

发起人
在这里插入图片描述

备忘录类
在这里插入图片描述

管理者类
白箱备忘录模式下,管理者是可以修改“备忘录”对象的。
在这里插入图片描述

主程序
白箱备忘录模式下,主程序也是可以修改“备忘录”对象的。
在这里插入图片描述

黑箱备忘录模式
备忘录角色对发起人对象提供一个宽接口(能访问备忘录里的数据),而为其他对象提供一个窄接口。在Java语言中,实现双重接口的版本就是将备忘录类设计成发起人类的内部成员类
在这里插入图片描述

发起人类
在这里插入图片描述

备忘录类
在这里插入图片描述

管理者类
在这里插入图片描述

优缺点

在这里插入图片描述

使用场景

在这里插入图片描述

11、解释器模式

概述

定义:
给定一个语言,定义它的文法表示,并定义一个解释器,这个解释器使用该标识来解释语言中的句子。

文法(语法)规则:
在这里插入图片描述
一种自定义的语法格式

抽象语法树:
在这里插入图片描述
从树最底层逐一往上运算

结构

**抽象表达式:**定义解释器的解释操作,主要包含解释器方法。
**终结符表达式:**是抽象表达式的子类,用来实现文法中与终结符相关的操作,文法中的每个终结符都有一个具体终结表达式与之相对应。
**非终结符表达式:**也是抽象表达式的子类,用来实现文法中与非终结符相关的操作,文法中的每条规则都对应于一个非终结符表达式。
**环境:**通常包含各个解释器需要的数据或是公共的功能,一般用来传递被所有解释器共享的数据,后面的解释器可以从这里获取这些值。
**客户端:**主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树,然后调用解释器的解释方法,当然也可以通过环境角色间接访问解释器的解释方法。

案例

在这里插入图片描述

抽象表达式类
在这里插入图片描述

终结表达式 - 变量类
在这里插入图片描述

环境类
在这里插入图片描述

非终结表达式 - 加法
在这里插入图片描述
减法表达式就由 + 变 -,不在此展示了。

主程序
在这里插入图片描述

优缺点

在这里插入图片描述

使用场景

在这里插入图片描述

  • 11
    点赞
  • 59
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
主要是介绍各种格式流行的软件设计模式,对于程序员的进一步提升起推进作用,有时间可以随便翻翻~~ 23设计模式汇集 如果你还不了解设计模式是什么的话? 那就先看设计模式引言 ! 学习 GoF 设计模式的重要性 建筑和软件中模式之异同 A. 创建模式 设计模式之 Singleton(单态/单件) 阎宏博士讲解:单例(Singleton)模式 保证一个类只有一个实例,并提供一个访问它的全局访问点 设计模式之 Factory(工厂方法和抽象工厂) 使用工厂模式就象使用 new 一样频繁. 设计模式之 Builder 汽车由车轮 方向盘 发动机很多部件组成,同时,将这些部件组装成汽车也是一件复杂的工作,Builder 模式就是将这两 种情况分开进行。 设计模式之 Prototype(原型) 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 B. 结构模式 设计模式之 Adapter(适配器) 使用类再生的两个方式:组合(new)和继承(extends),这个已经在 thinking in java中提到过. 设计模式之 Proxy(代理) 以 Jive 为例,剖析代理模式在用户级别授权机制上的应用 设计模式之 Facade(门面?) 可扩展的使用 JDBC针对不同的数据库编程,Facade提供了一种灵活的实现. 设计模式之 Composite(组合) 就是将类用树形结构组合成一个单位.你向别人介绍你是某单位,你是单位中的一个元素,别人和你做买卖,相当于 和单位做买卖。文章中还对 Jive再进行了剖析。 设计模式之 Decorator(装饰器) Decorator 是个油漆工,给你的东东的外表刷上美丽的颜色. 设计模式之 Bridge(桥连) 将牛郎织女分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合) 设计模式之 Flyweight(共享元) 提供 Java运行性能,降低小而大量重复的类的开销. C. 行为模式 设计模式之 Command(命令) 什么是将行为封装,Command 是最好的说明. 设计模式之 Observer(观察者) 介绍如何使用 Java API 提供的现成 Observer 设计模式之 Iterator(迭代器) 这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中, 直接使用 Iterator 进行对象遍历。 设计模式之 Template(模板方法) 实际上向你介绍了为什么要使用 Java 抽象类,该模式原理简单,使用很普遍. 设计模式之 Strategy(策略) 不同算法各自封装,用户端可随意挑选需要的算法. 设计模式之 Chain of Responsibility(责任链) 各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个. 设计模式之 Mediator(中介) Mediator 很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以. 设计模式之 State(状态) 状态是编程中经常碰到的实例,将状态对象化,设立状态变换器,便可在状态中轻松切换. 设计模式之 Memento(注释状态?) 很简单一个模式,就是在内存中保留原来数据的拷贝. 设计模式之 Interpreter(解释器) 主要用来对语言的分析,应用机会不多. 设计模式之 Visitor(访问者) 访问者在进行访问时,完成一系列实质性操作,而且还可以扩展. 设计模式引言 设计面向对象软件比较困难,而设计可复用的面向对象软件就更加困难。你必须找到相关的对象,以适当的粒度将它们归 类,再定义类的接口和继承层次,建立对象之间的基本关系。你的设计应该对手头的问题有针对性,同时对将来的问题和需求 也要有足够的通用性。 你也希望避免重复设计或尽可能少做重复设计。有经验的面向对象设计者会告诉你,要一下子就得到复用性和灵活性好的设计, 即使不是不可能的至少也是非常困难的。一个设计在最终完成之前常要被复用好几次,而且每一次都有所修改。 有经验的面向对象设计者的确能做出良好的设计,而新手则面对众多选择无从下手,总是求助于以前使用过的非面向对象 技术。新手需要花费较长时间领会良好的面向对象设计是怎么回事。有经验的设计者显然知道一些新手所不知道的东西,这又 是什么呢? 内行的设计者知道:不是解决任何问题都要从头做起。他们更愿意复用以前使用过的解决方案。当找到一个好的解决方案,他 们会一遍又一遍地使用。这些经验是他们成为内行的部分原因。因此,你会在许多面向对象系统中看到类和相互通信的对象( c o m m u n i c a t i n go b j e c t)的重复模式。这些模式解决特定的设计问题,使面向对象设计更灵活、优雅,最终复用性更 好。它们帮助设计者将新的设计建立在以往工作的基础上,复用以往成功的设计方案。 一个熟悉这些模式的设计者不需要再去发现它们,而能够立即将它们应用于设计问题中。以下类比可以帮助说明这一点。 小说家和剧本作家很少从头开始设计剧情。他们总是沿袭一些业已存在的模式,像“悲剧性英雄”模式(《麦克白》、《哈姆雷特》 等)或“浪漫小说”模式(存在着无数浪漫小说)。同样地,面向对象设计员也沿袭一些模式,像“用对象表示状态”和“修饰对象以便 于你能容易地添加/删除属性”等。一旦懂得了模式,许多设计决策自然而然就产生了。 我们都知道设计经验的重要价值。你曾经多少次有过这种感觉—你已经解决过了一个问题但就是不能确切知道是在什么地 方或怎么解决的?如果你能记起以前问题的细节和怎么解决它的,你就可以复用以前的经验而不需要重新发现它。然而,我们 并没有很好记录下可供他人使用的软件设计经验。 学习 GoF设计模式的重要性 著名的 EJB 领域顶尖的专家 Richard Monson-Haefel 在其个人网站:www.EJBNow.com 中极力推荐的 GoF 的《设计模式》,原文 如下: Design Patterns Most developers claim to experience an epiphany reading this book. If you've never read the Design Patterns book then you have suffered a very serious gap in your programming education that should be remedied immediately. 翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读 过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补! 可以这么说:GoF 设计模式是程序员真正掌握面向对象核心思想的必修课。虽然你可能已经通过了 SUN 的很多令人炫目的 技术认证,但是如果你没有学习掌握 GoF 设计模式,只能说明你还是一个技工。 在浏览《Thingking in Java》(第一版)时,你是不是觉得好象这还是一本 Java 基础语言书籍?但又不纯粹是,因为这本书的作 者将面向对象的思想巧妙的融合在 Java 的具体技术上,潜移默化的让你感觉到了一种新的语言和新的思想方式的诞生。 但是读完这本书,你对书中这些蕴含的思想也许需要一种更明晰更系统更透彻的了解和掌握,那么你就需要研读 GoF 的《设 计模式》了。 《Thingking in Java》(第一版中文)是这样描述设计模式的:他在由 Gamma, Helm 和 Johnson Vlissides 简称 Gang of Four(四人 帮),缩写 GoF 编著的《Design Patterns》一书中被定义成一个“里程碑”。事实上,那本书现在已成为几乎所有 OOP(面向对象程 序设计)程序员都必备的参考书。(在国外是如此)。 GoF 的《设计模式》是所有面向对象语言(C++ Java C#)的基础,只不过不同的语言将之实现得更方便地使用。 GOF 的设计模式是一座"桥" 就 Java 语言体系来说,GOF 的设计模式Java 基础知识和 J2EE 框架知识之间一座隐性的"桥"。 会 Java 的人越来越多,但是一直徘徊在语言层次的程序员不在少数,真正掌握 Java 中接口或抽象类的应用不是很多,大家 经常以那些技术只适合大型项目为由,避开或忽略它们,实际中,Java 的接口或抽象类是真正体现 Java 思想的核心所在,这些 你都将在 GoF 的设计模式里领略到它们变幻无穷的魔力。 GoF 的设计模式表面上好象也是一种具体的"技术",而且新的设计模式不断在出现,设计模式自有其自己的发展轨道,而这 些好象和 J2EE .Net 等技术也无关! 实际上,GoF 的设计模式并不是一种具体"技术",它讲述的是思想,它不仅仅展示了接口或抽象类在实际案例中的灵活应用 和智慧,让你能够真正掌握接口或抽象类的应用,从而在原来的 Java 语言基础上跃进一步,更重要的是,GoF 的设计模式反复 向你强调一个宗旨:要让你的程序尽可能的可重用。 这其实在向一个极限挑战:软件需求变幻无穷,计划没有变化快,但是我们还是要寻找出不变的东西,并将它和变化的东 西分离开来,这需要非常的智慧和经验。 而 GoF 的设计模式是在这方面开始探索的一块里程碑。 J2EE 等属于一种框架软件,什么是框架软件?它不同于我们以前接触的 Java API 等,那些属于 Toolkist(工具箱),它不再被动 的被使用,被调用,而是深刻的介入到一个领域中去,J2EE 等框架软件设计的目的是将一个领域中不变的东西先定义好,比如 整体结构和一些主要职责(如数据库操作 事务跟踪 安全等),剩余的就是变化的东西,针对这个领域中具体应用产生的具体不同 的变化需求,而这些变化东西就是 J2EE 程序员所要做的。 由此可见,设计模式和 J2EE 在思想和动机上是一脉相承,只不过 1.设计模式更抽象,J2EE 是具体的产品代码,我们可以接触到,而设计模式在对每个应用时才会产生具体代码。 2.设计模式是比 J2EE 等框架软件更小的体系结构,J2EE 中许多具体程序都是应用设计模式来完成的,当你深入到 J2EE 的内 部代码研究时,这点尤其明显,因此,如果你不具备设计模式的基础知识(GoF 的设计模式),你很难快速的理解 J2EE。不能理解 J2EE,如何能灵活应用? 3.J2EE 只是适合企业计算应用的框架软件,但是 GoF 的设计模式几乎可以用于任何应用!因此 GoF 的设计模式应该是 J2EE 的重要理论基础之一。 所以说,GoF 的设计模式Java 基础知识和 J2EE 框架知识之间一座隐性的"桥"。为什么说隐性的? GOF 的设计模式是一座隐性的"桥" 因为很多人没有注意到这点,学完 Java 基础语言就直接去学 J2EE,有的甚至鸭子赶架,直接使用起 Weblogic 等具体 J2EE 软 件,一段时间下来,发现不过如此,挺简单好用,但是你真正理解 J2EE 了吗?你在具体案例中的应用是否也是在延伸 J2EE 的思 想? 如果你不能很好的延伸 J2EE 的思想,那你岂非是大炮轰蚊子,认识到 J2EE 不是适合所有场合的人至少是明智的,但我们更 需要将 J2EE 用对地方,那么只有理解 J2EE 此类框架软件的精髓,那么你才能真正灵活应用 Java 解决你的问题,甚至构架出你自 己企业的框架来。(我们不能总是使用别人设定好的框架,为什么不能有我们自己的框架?) 因此,首先你必须掌握 GoF 的设计模式。虽然它是隐性,但不是可以越过的。 关于本站“设计模式Java 提供了丰富的 API,同时又有强大的数据库系统作底层支持,那么我们的编程似乎变成了类似积木的简单"拼凑"和调用, 甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至. 在真正可复用的面向对象编程中,GoF 的《设计模式》为我们提供了一套可复用的面向对象技术,再配合 Refactoring(重构方法), 所以很少存在简单重复的工作,加上Java 代码的精炼性和面向对象纯洁性(设计模式java 的灵魂),编程工作将变成一个让你时刻 体验创造快感的激动人心的过程. 为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解 GoF 的《设计模式》。由 于原著都是以C++为例, 以Java为例的设计模式基本又都以图形应用为例,而我们更关心Java在中间件等服务器方面的应用,因此, 本站所有实例都是非图形应用,并且顺带剖析 Jive论坛系统.同时为降低理解难度,尽量避免使用 UML 图. 如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就 培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀 程序员的必备条件. 整个设计模式贯穿一个原理:面对接口编程,而不是面对实现.目标原则是:降低耦合,增强灵活性. 建筑和软件中模式之异同 CSDN 的透明特别推崇《建筑的永恒之道》,认为从中探寻到软件的永恒之道,并就"设计模式"写了专门文章《探寻软件的永恒 之道 》,其中很多观点我看了很受启发,以前我也将"设计模式" 看成一个简单的解决方案,没有从一种高度来看待"设计模式"在软 件中地位,下面是我自己的一些想法: 建筑和软件某些地方是可以来比喻的 特别是中国传统建筑,那是很讲模式的,这些都是传统文化使然,比如京剧 一招一式都有套路;中国画,也有套路,树应该怎么画 法?有几种画法?艺术大家通常是创造出自己的套路,比如明末清初,水墨画法开始成熟,这时画树就不用勾勒这个模式了,而是一笔 下去,浓淡几个叶子,待毛笔的水墨要干枯时,画一下树干,这样,一个活生写意的树就画出来. 我上面这些描述其实都是一种模式,创建模式的人是大师,但是拘泥于模式的人永远是工匠. 再回到传统建筑中,中国的传统建筑是过分注重模式了,所以建筑风格发展不大,基本分南北两派,大家有个感觉,旅游时,到南 方,你发现古代名居建筑都差不多;北方由于受满人等少数民族的影响,在建筑色彩上有些与南方迥异,但是很多细节地方都差不多. 这些都是模式的体现. 由于建筑受材料和功用以及费用的影响,所用模式种类不多,这点是和软件很大的不同. 正因为这点不同,导致建筑的管理模式和软件的管理模式就有很多不同, 有些人认识不到这点,就产生了可以大量使用"软件 蓝领"的想法,因为他羡慕建筑中"民工"的低成本. 要知道软件还有一个与建筑截然相反的责任和用途,那就是:现代社会中,计划感不上变化,竞争激烈,所有一切变幻莫测,要应 付所有这些变化,首推信息技术中的软件,只有软件能够帮助人类去应付各种变化.而这点正好与建筑想反,建筑是不能帮助人类去 应付变化的,(它自己反而要求稳固,老老实实帮助人遮风避雨,总不能叫人类在露天或树叶下打开电脑编软件吧). 软件要帮助人类去应付变化,这是软件的首要责任,所以,软件中模式产生的目的就和建筑不一样了,建筑中的模式产生可以因 为很多原因:建筑大师的创意;材料的革新等;建筑中这些模式一旦产生,容易发生另外一个缺点,就是有时会阻碍建筑本身的发展, 因为很多人会不思创造,反复使用老的模式进行设计,阻碍建筑的发展. 但是在软件中,这点正好相反,软件模式的产生是因为变化的东西太多,为减轻人类的负担,将一些不变的东西先用模式固化,这 样让人类可以更加集中精力对付变化的东西,所以在软件中大量反复使用模式(我个人认为这样的软件就叫框架软件了,比如J2EE), 不但没阻碍软件的发展,反而是推动了软件的发展.因为其他使用这套软件的人就可以将更多精力集中在对付那些无法用模式的 应用上来. 可以关于建筑和软件中的模式作用可以总结如下: 在软件中,模式是帮助人类向"变化"战斗,但是在软件中还需要和'变化'直接面对面战斗的武器:人的思维,特别是创造 分析思 维等等,这些是软件真正的灵魂,这种思维可以说只要有实践需求(如有新项目)就要求发生,发生频度高,人类的创造或分析思 维决定了软件的质量和特点。 而在建筑中,模式可以构成建筑全部知识,当有新的需求(如有新项目),一般使用旧的模式都可以完成,因此对人类的创造以 及分析思维不是每个项目都必须的,也不是非常重要的,对创造性的思维的需求只是属于锦上添花(除非人类以后离开地球居 住了〕。 设计模式之 Singleton(单态) 模式实战书籍《Java实用系统开发指南》 单态定义: Singleton 模式主要作用是保证在 Java 应用程序中,一个类 Class 只有一个实例存在。 在很多操作中,比如建立目录 数据库连接都需要这样的单线程操作。 还有, singleton 能够被状态化; 这样,多个单态类在一起就可以作为一个状态仓库一样向外提供服务,比如,你要论坛中的 帖子计数器,每次浏览一次需要计数,单态类能否保持住这个计数,并且能 synchronize 的安全自动加 1,如果你要把这个数字 永久保存到数据库,你可以在不修改单态接口的情况下方便的做到。 另外方面,Singleton 也能够被无状态化。提供工具性质的功能, Singleton 模式就为我们提供了这样实现的可能。使用 Singleton 的好处还在于可以节省内存,因为它限制了实例的个数,有 利于 Java 垃圾回收(garbage collection)。 我们常常看到工厂模式中类装入器(class loader)中也用 Singleton 模式实现的,因为被装入的类实际也属于资源。 如何使用? 一般 Singleton 模式通常有几种形式: public class Singleton { private Singleton(){} //在自己内部定义自己一个实例,是不是很奇怪? //注意这是 private 只供内部调用 private static Singleton instance = new Singleton(); //这里提供了一个供外部访问本 class 的静态方法,可以直接访问 public static Singleton getInstance() { return instance; } } 第二种形式: public class Singleton { private static Singleton instance = null; public static synchronized Singleton getInstance() { //这个方法比上面有所改进,不用每次都进行生成对象,只是第一次 //使用时生成实例,提高了效率! if (instance==null) instance=new Singleton(); return instance; } } 使用 Singleton.getInstance()可以访问单态类。 上面第二中形式是 lazy initialization,也就是说第一次调用时初始 Singleton,以后就不用再生成了。 注意到 lazy initialization 形式中的 synchronized,这个 synchronized 很重要,如果没有 synchronized,那么使用 getInstance() 是有可能得到多个 Singleton 实例。关于 lazy initialization 的 Singleton 有很多涉及 double-checked locking (DCL)的讨论,有兴趣者 进一步研究。 一般认为第一种形式要更加安全些。 使用 Singleton 注意事项: 有时在某些情况下,使用 Singleton 并不能达到 Singleton 的目的,如有多个 Singleton 对象同时被不同的类装入器装载;在 EJB 这样的分布式系统中使用也要注意这种情况,因为 EJB 是跨服务器,跨 JVM 的。 我们以 SUN 公司的宠物店源码(Pet Store 1.3.1)的 ServiceLocator 为例稍微分析一下: 在 Pet Store中 ServiceLocator 有两种,一个是 EJB 目录下;一个是 WEB 目录下,我们检查这两个 ServiceLocator 会发现内容 差不多,都是提供 EJB 的查询定位服务,可是为什么要分开呢?仔细研究对这两种 ServiceLocator 才发现区别:在 WEB 中的 ServiceLocator 的采取 Singleton 模式,ServiceLocator 属于资源定位,理所当然应该使用 Singleton 模式。但是在 EJB 中,Singleton 模式已经失去作用,所以 ServiceLocator 才分成两种,一种面向 WEB 服务的,一种是面向 EJB 服务的。 Singleton 模式看起来简单,使用方法也很方便,但是真正用好,是非常不容易,需要对 Java 的类 线程 内存等概念有相当 的了解。 总之:如果你的应用基于容器,那么 Singleton 模式少用或者不用,可以使用相关替代技术。 进一步深入可参考: Double-checked locking and the Singleton pattern When is a singleton not a singleton? 设计模式如何在具体项目中应用见《Java 实用系统开发指南》。 设计模式之 Factory 工厂模式定义:提供创建对象的接口. 为何使用? 工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式,工厂模式在Java程序系统可以说是随处可见。 为什么工厂模式是如此常用?因为工厂模式就相当于创建实例对象的 new,我们经常要根据类 Class 生成实例对象,如 A a=new A() 工厂模式也是用来创建实例对象的,所以以后 new时就要多个心眼,是否可以考虑实用工厂模式,虽然这样做, 可能多做一些工作,但会给你系统带来更大的可扩展性和尽量少的修改量。 我们以类 Sample为例, 如果我们要创建 Sample的实例对象: Sample sample=new Sample(); 可是,实际情况是,通常我们都要在创建 sample实例时做点初始化的工作,比如赋值 查询数据库等。 首先,我们想到的是,可以使用 Sample的构造函数,这样生成实例就写成: Sample sample=new Sample(参数); 但是,如果创建 sample 实例时所做的初始化工作不是象赋值这样简单的事,可能是很长一段代码,如果也写入构造函数 中,那你的代码很难看了(就需要 Refactor 重整)。 为什么说代码很难看,初学者可能没有这种感觉,我们分析如下,初始化工作如果是很长一段代码,说明要做的工作很多, 将很多工作装入一个方法中,相当于将很多鸡蛋放在一个篮子里,是很危险的,这也是有背于 Java 面向对象的原则,面向对象 的封装(Encapsulation)和分派(Delegation)告诉我们,尽量将长的代码分派“切割”成每段,将每段再“封装”起来(减少段和段 之间偶合联系性),这样,就会将风险分散,以后如果需要修改,只要更改每段,不会再发生牵一动百的事情。 在本例中,首先,我们需要将创建实例的工作与使用实例的工作分开, 也就是说,让创建实例所需要的大量初始化工作从 Sample的构造函数中分离出去。 这时我们就需要 Factory 工厂模式来生成对象了,不能再用上面简单 new Sample(参数)。还有,如果 Sample 有个继承 如 MySample, 按照面向接口编程,我们需要将 Sample 抽象成一个接口.现在 Sample 是接口,有两个子类 MySample 和 HisSample .我们要实例化他们时,如下: Sample mysample=new MySample(); Sample hissample=new HisSample(); 随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以 前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的. 但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了. 工厂方法 你会建立一个专门生产 Sample实例的工厂: public class Factory{ public static Sample creator(int which){ //getClass 产生 Sample 一般可使用动态类装载装入类。 if (which==1) return new SampleA(); else if (which==2) return new SampleB(); } } 那么在你的程序中,如果要实例化 Sample 时.就使用 Sample sampleA=Factory.creator(1); 这样,在整个就不涉及到 Sample 的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻: 就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可 能性就越少.好象我们从编程序中也能悟出人生道理?呵呵. 使用工厂方法 要注意几个角色,首先你要定义产品接口,如上面的 Sample,产品接口下有 Sample接口的实现类,如 SampleA,其次要有一个 factory 类,用来生成产品 Sample,如下图,最右边是生产的对象 Sample: 进一步稍微复杂一点,就是在工厂类上进行拓展,工厂类也有继承它的实现类 concreteFactory 了。 抽象工厂 工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory). 这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象 Sample,如果我们还有新的产品接口 Sample2. 这里假设:Sample有两个 concrete 类 SampleA 和 SamleB,而 Sample2 也有两个 concrete类 Sample2A 和 SampleB2 那么,我们就将上例中 Factory 变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现,下面就是将上例中的 Factory 拓展成抽象工厂: public abstract class Factory{ public abstract Sample creator(); public abstract Sample2 creator(String name); } public class SimpleFactory extends Factory{ public Sample creator(){ ......... return new SampleA } public Sample2 creator(String name){ ......... return new Sample2A } } public class BombFactory extends Factory{ public Sample creator(){ ...... return new SampleB } public Sample2 creator(String name){ ...... return new Sample2B } } 从上面看到两个工厂各自生产出一套 Sample和 Sample2,也许你会疑问,为什么我不可以使用两个工厂方法来分别生产 Sample和 Sample2? 抽象工厂还有另外一个关键要点,是因为 SimpleFactory 内,生产 Sample和生产 Sample2 的方法之间有一定联系, 所以才要将这两个方法捆绑在一个类中,这个工厂类有其本身特征,也许制造过程是统一的,比如:制造工艺比较简单,所以 名称叫 SimpleFactory。 在实际应用中,工厂方法用得比较多一些,而且是和动态类装入器组合在一起应用, 举例 我们以 Jive的 ForumFactory 为例,这个例子在前面的 Singleton 模式中我们讨论过,现在再讨论其工厂模式: public abstract class ForumFactory { private static Object initLock = new Object(); private static String className = "com.jivesoftware.forum.database.DbForumFactory"; private static ForumFactory factory = null; public static ForumFactory getInstance(Authorization authorization) { //If no valid authorization passed in, return null. if (authorization == null) { return null; } //以下使用了 Singleton 单态模式 if (factory == null) { synchronized(initLock) { if (factory == null) { ...... try { //动态转载类 Class c = Class.forName(className); factory = (ForumFactory)c.newInstance(); } catch (Exception e) { return null; } } } } //Now, 返回 proxy.用来限制授权对 forum 的访问 return new ForumFactoryProxy(authorization, factory, factory.getPermissions(authorization)); } //真正创建 forum 的方法由继承 forumfactory 的子类去完成. public abstract Forum createForum(String name, String description) throws UnauthorizedException, ForumAlreadyExistsException; .... } 因为现在的 Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法 ForumFactory 就提供了提供动态接口: private static String className = "com.jivesoftware.forum.database.DbForumFactory"; 你可以使用自己开发的创建 forum 的方法代替 com.jivesoftware.forum.database.DbForumFactory 就可以. 在上面的一段代码中一共用了三种模式,除了工厂模式外,还有 Singleton 单态模式,以及 proxy模式,proxy 模式主要用来 授权用户对 forum 的访问,因为访问 forum 有两种人:一个是注册用户 一个是游客 guest,那么那么相应的权限就不一样,而且 这个权限是贯穿整个系统的,因此建立一个 proxy,类似网关的概念,可以很好的达到这个效果. 看看 Java 宠物店中的 CatalogDAOFactory: public class CatalogDAOFactory { /** * 本方法制定一个特别的子类来实现 DAO 模式。 * 具体子类定义是在 J2EE 的部署描述器中。 */ public static CatalogDAO getDAO() throws CatalogDAOSysException { CatalogDAO catDao = null; try { InitialContext ic = new InitialContext(); //动态装入 CATALOG_DAO_CLASS //可以定义自己的 CATALOG_DAO_CLASS,从而在无需变更太多代码 //的前提下,完成系统的巨大变更。 String className =(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS); catDao = (CatalogDAO) Class.forName(className).newInstance(); } catch (NamingException ne) { throw new CatalogDAOSysException(" CatalogDAOFactory.getDAO: NamingException while getting DAO type : \n" + ne.getMessage()); } catch (Exception se) { throw new CatalogDAOSysException(" CatalogDAOFactory.getDAO: Exception while getting DAO type : \n" + se.getMessage()); } return catDao; } } CatalogDAOFactory 是典型的工厂方法, catDao 是通过动态类装入器 className 获得 CatalogDAOFactory 具体实现 子类,这个实现子类在 Java 宠物店是用来操作 catalog 数据库,用户可以根据数据库的类型不同,定制自己的具体实现子类, 将自己的子类名给与 CATALOG_DAO_CLASS 变量就可以。 由此可见,工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制,只要我们更换一下具体的工厂方法,系统其他 地方无需一点变换,就有可能将系统功能进行改头换面的变化。 设计模式之 Builder Builder 模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. Builder 模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知 道内部的具体构建细节.Builder 模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到. 为何使用? 是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件. 因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但 远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder 模式就是为了将部件和组装 过程分开. 如何使用? 首先假设一个复杂对象是由多个部件组成的,Builder 模式是把复杂对象的创建和部件的创建分别开来,分别用 Builder 类和 Director 类来表示. 首先,需要一个接口,它定义如何创建复杂对象的各个部件: public interface Builder { //创建部件 A 比如创建汽车车轮 void buildPartA(); //创建部件 B 比如创建汽车方向盘 void buildPartB(); //创建部件 C 比如创建汽车发动机 void buildPartC(); //返回最后组装成品结果 (返回最后装配好的汽车) //成品的组装过程不在这里进行,而是转移到下面的 Director 类中进行. //从而实现了解耦过程和部件 Product getResult(); } 用 Director 构建最后的复杂对象,而在上面 Builder 接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就 是说 Director 的内容是如何将部件最后组装成成品: public class Director { private Builder builder; public Director( Builder builder ) { this.builder = builder; } // 将部件 partA partB partC 最后组成复杂对象 //这里是将车轮 方向盘和发动机组装成汽车的过程 public void construct() { builder.buildPartA(); builder.buildPartB(); builder.buildPartC(); } } Builder 的具体实现 ConcreteBuilder: 通过具体完成接口 Builder 来构建或装配产品的部件; 定义并明确它所要创建的是什么具体东西; 提供一个可以重新获取产品的接口: public class ConcreteBuilder implements Builder { Part partA, partB, partC; public void buildPartA() { //这里是具体如何构建 partA 的代码 }; public void buildPartB() { //这里是具体如何构建 partB 的代码 }; public void buildPartC() { //这里是具体如何构建 partB 的代码 }; public Product getResult() { //返回最后组装成品结果 }; } 复杂对象:产品 Product: public interface Product { } 复杂对象的部件: public interface Part { } 我们看看如何调用 Builder 模式: ConcreteBuilder builder = new ConcreteBuilder(); Director director = new Director( builder ); director.construct(); Product product = builder.getResult(); Builder 模式的应用 在 Java 实际使用中,我们经常用到"池"(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共 享时,就需要使用池. "池"实际是一段内存,当池中有一些复杂的资源的"断肢"(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这 些"断肢",将提高内存使用效率,提高池的性能.修改 Builder 模式中 Director 类使之能诊断"断肢"断在哪个部件上,再修复这个部件. 设计模式之 Prototype(原型) 原型模式定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象. Prototype模式允许一个对象再创建另外一个可定制的对象,根本无需知道任何如何创建的细节,工作原理是:通过将一个 原型对象传给那个要发动创建的对象,这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。 如何使用? 因为 Java 中的提供 clone()方法来实现对象的克隆,所以 Prototype模式实现一下子变得很简单. 以勺子为例: public abstract class AbstractSpoon implements Cloneable { String spoonName; public void setSpoonName(String spoonName) {this.spoonName = spoonName;} public String getSpoonName() {return this.spoonName;} public Object clone() { Object object = null; try { object = super.clone(); } catch (CloneNotSupportedException exception) { System.err.println("AbstractSpoon is not Cloneable"); } return object; } } 有个具体实现(ConcretePrototype): public class SoupSpoon extends AbstractSpoon { public SoupSpoon() { setSpoonName("Soup Spoon"); } } 调用 Prototype 模式很简单: AbstractSpoon spoon = new SoupSpoon(); AbstractSpoon spoon2 = spoon.clone(); 当然也可以结合工厂模式来创建 AbstractSpoon 实例。 在 Java 中 Prototype 模式变成 clone()方法的使用,由于 Java 的纯洁的面向对象特性,使得在 Java 中使用设计模式变 得很自然,两者已经几乎是浑然一体了。这反映在很多模式上,如 Interator 遍历模式。 设计模式之 Adapter(适配器) 适配器模式定义: 将两个不兼容的类纠合在一起使用,属于结构型模式,需要有 Adaptee(被适配者)和 Adaptor(适配器)两个身份. 为何使用? 我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是:修改各自类的接口,但是如果我们没有源代码,或 者,我们不愿意为了一个应用而修改各自的接口。 怎么办? 使用 Adapter,在这两种接口之间创建一个混合接口(混血儿). 如何使用? 实现 Adapter 方式,其实"think in Java"的"类再生"一节中已经提到,有两种方式:组合(composition)和继承 (inheritance). 假设我们要打桩,有两种类:方形桩 圆形桩. public class SquarePeg{ public void insert(String str){ System.out.println("SquarePeg insert():"+str); } } public class RoundPeg{ public void insertIntohole(String msg){ System.out.println("RoundPeg insertIntoHole():"+msg); } } 现在有一个应用,需要既打方形桩,又打圆形桩.那么我们需要将这两个没有关系的类综合应用.假设 RoundPeg 我们没有源 代码,或源代码我们不想修改,那么我们使用 Adapter 来实现这个应用: public class PegAdapter extends SquarePeg{ private RoundPeg roundPeg; public PegAdapter(RoundPeg peg)(this.roundPeg=peg;) public void insert(String str){ roundPeg.insertIntoHole(str);} } 在上面代码中,RoundPeg 属于 Adaptee,是被适配者.PegAdapter 是 Adapter,将 Adaptee(被适配者 RoundPeg)和 Target(目标 SquarePeg)进行适配.实际上这是将组合方法(composition)和继承(inheritance)方法综合运用. PegAdapter 首先继承 SquarePeg,然后使用 new 的组合生成对象方式,生成 RoundPeg 的对象 roundPeg,再重载父 类 insert()方法。从这里,你也了解使用 new生成对象和使用 extends 继承生成对象的不同,前者无需对原来的类修改,甚至无 需要知道其内部结构和源代码. 如果你有些 Java 使用的经验,已经发现,这种模式经常使用。 进一步使用 上面的 PegAdapter 是继承了 SquarePeg,如果我们需要两边继承,即继承 SquarePeg 又继承 RoundPeg,因为 Java 中 不允许多继承,但是我们可以实现(implements)两个接口(interface) public interface IRoundPeg{ public void insertIntoHole(String msg); } public interface ISquarePeg{ public void insert(String str); } 下面是新的 RoundPeg 和 SquarePeg, 除了实现接口这一区别,和上面的没什么区别。 public class SquarePeg implements ISquarePeg{ public void insert(String str){ System.out.println("SquarePeg insert():"+str); } } public class RoundPeg implements IRoundPeg{ public void insertIntohole(String msg){ System.out.println("RoundPeg insertIntoHole():"+msg); } } 下面是新的 PegAdapter,叫做 two-way adapter: public class PegAdapter implements IRoundPeg,ISquarePeg{ private RoundPeg roundPeg; private SquarePeg squarePeg; // 构造方法 public PegAdapter(RoundPeg peg){this.roundPeg=peg;} // 构造方法 public PegAdapter(SquarePeg peg)(this.squarePeg=peg;) public void insert(String str){ roundPeg.insertIntoHole(str);} } 还有一种叫 Pluggable Adapters,可以动态的获取几个 adapters 中一个。使用 Reflection 技术,可以动态的发现类中的 Public 方法。 设计模式之 Proxy(代理) 理解并使用设计模式,能够培养我们良好的面向对象编程习惯,同时在实际应用中,可以如鱼得水,享受游刃有余的乐趣. 代理模式是比较有用途的一种模式,而且变种较多,应用场合覆盖从小结构到整个系统的大结构,Proxy 是代理的意思,我们 也许有代理服务器等概念,代理概念可以解释为:在出发点到目的地之间有一道中间层,意为代理. 设计模式中定义: 为其他对象提供一种代理以控制对这个对象的访问. 为什么要使用 Proxy? 1.授权机制 不同级别的用户对同一对象拥有不同的访问权利,如 Jive 论坛系统中,就使用 Proxy 进行授权机制控制,访问 论坛有两种人:注册用户和游客(未注册用户),Jive 中就通过类似 ForumProxy 这样的代理来控制这两种用户对论坛的访问权 限. 2.某个客户端不能直接操作到某个对象,但又必须和那个对象有所互动. 举例两个具体情况: (1)如果那个对象是一个是很大的图片,需要花费很长时间才能显示出来,那么当这个图片包含在文档中时,使用编辑器或浏 览器打开这个文档,打开文档必须很迅速,不能等待大图片处理完成,这时需要做个图片 Proxy 来代替真正的图片. (2)如果那个对象在 Internet 的某个远端服务器上,直接操作这个对象因为网络速度原因可能比较慢,那我们可以先用 Proxy来代替那个对象. 总之原则是,对于开销很大的对象,只有在使用它时才创建,这个原则可以为我们节省很多宝贵的 Java 内存. 所以,有些人认 为 Java 耗费资源内存,我以为这和程序编制思路也有一定的关系. 如何使用 Proxy? 以 Jive 论坛系统为例,访问论坛系统的用户有多种类型:注册普通用户 论坛管理者 系统管理者 游客,注册普通用户才能发 言;论坛管理者可以管理他被授权的论坛;系统管理者可以管理所有事务等,这些权限划分和管理是使用 Proxy完成的. Forum 是 Jive的核心接口,在 Forum 中陈列了有关论坛操作的主要行为,如论坛名称 论坛描述的获取和修改,帖子发表删 除编辑等. 在 ForumPermissions 中定义了各种级别权限的用户: public class ForumPermissions implements Cacheable { /** * Permission to read object. */ public static final int READ = 0; /** * Permission to administer the entire sytem. */ public static final int SYSTEM_ADMIN = 1; /** * Permission to administer a particular forum. */ public static final int FORUM_ADMIN = 2; /** * Permission to administer a particular user. */ public static final int USER_ADMIN = 3; /** * Permission to administer a particular group. */ public static final int GROUP_ADMIN = 4; /** * Permission to moderate threads. */ public static final int MODERATE_THREADS = 5; /** * Permission to create a new thread. */ public static final int CREATE_THREAD = 6; /** * Permission to create a new message. */ public static final int CREATE_MESSAGE = 7; /** * Permission to moderate messages. */ public static final int MODERATE_MESSAGES = 8; ..... public boolean isSystemOrForumAdmin() { return (values[FORUM_ADMIN] || values[SYSTEM_ADMIN]); } ..... } 因此,Forum 中各种操作权限是和 ForumPermissions 定义的用户级别有关系的,作为接口 Forum 的实现:ForumProxy 正是将这种对应关系联系起来.比如,修改 Forum 的名称,只有论坛管理者或系统管理者可以修改,代码如下: public class ForumProxy implements Forum { private ForumPermissions permissions; private Forum forum; this.authorization = authorization; public ForumProxy(Forum forum, Authorization authorization, ForumPermissions permissions) { this.forum = forum; this.authorization = authorization; this.permissions = permissions; } ..... public void setName(String name) throws UnauthorizedException, ForumAlreadyExistsException { //只有是系统或论坛管理者才可以修改名称 if (permissions.isSystemOrForumAdmin()) { forum.setName(name); } else { throw new UnauthorizedException(); } } ... } 而 DbForum 才是接口 Forum 的真正实现,以修改论坛名称为例: public class DbForum implements Forum, Cacheable { ... public void setName(String name) throws ForumAlreadyExistsException { .... this.name = name; //这里真正将新名称保存到数据库中 saveToDb(); .... } ... } 凡是涉及到对论坛名称修改这一事件,其他程序都首先得和ForumProxy打交道,由ForumProxy决定是否有权限做某一样 事情,ForumProxy 是个名副其实的"网关","安全代理系统". 在平时应用中,无可避免总要涉及到系统的授权或安全体系,不管你有无意识的使用 Proxy,实际你已经在使用 Proxy了. 我们继续结合 Jive谈入深一点,下面要涉及到工厂模式了,如果你不了解工厂模式,请看我的另外一篇文章:设计模式之 Factory 我们已经知道,使用 Forum 需要通过 ForumProxy,Jive 中创建一个 Forum 是使用 Factory 模式,有一个总的抽象类 ForumFactory,在这个抽象类中,调用 ForumFactory 是通过 getInstance()方法实现,这里使用了 Singleton(也是设计模式 之一,由于介绍文章很多,我就不写了),getInstance()返回的是 ForumFactoryProxy. 为什么不返回 ForumFactory,而返回 ForumFactory 的实现 ForumFactoryProxy? 原因是明显的,需要通过代理确定是否有权限创建 forum. 在 ForumFactoryProxy 中我们看到代码如下: public class ForumFactoryProxy extends ForumFactory { protected ForumFactory factory; protected Authorization authorization; protected ForumPermissions permissions; public ForumFactoryProxy(Authorization authorization, ForumFactory factory, ForumPermissions permissions) { this.factory = factory; this.authorization = authorization; this.permissions = permissions; } public Forum createForum(String name, String description) throws UnauthorizedException, ForumAlreadyExistsException { //只有系统管理者才可以创建 forum if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) { Forum newForum = factory.createForum(name, description); return new ForumProxy(newForum, authorization, permissions); } else { throw new UnauthorizedException(); } } 方法 createForum 返回的也是 ForumProxy, Proxy 就象一道墙,其他程序只能和 Proxy交互操作. 注意到这里有两个 Proxy:ForumProxy 和 ForumFactoryProxy. 代表两个不同的职责:使用 Forum 和创建 Forum; 至于为什么将使用对象和创建对象分开,这也是为什么使用 Factory 模式的原因所在:是为了"封装" "分派";换句话说,尽可 能功能单一化,方便维护修改. Jive论坛系统中其他如帖子的创建和使用,都是按照 Forum 这个思路而来的. 以上我们讨论了如何使用Proxy进行授权机制的访问,Proxy还可以对用户隐藏另外一种称为copy-on-write的优化方式. 拷贝一个庞大而复杂的对象是一个开销很大的操作,如果拷贝过程中,没有对原来的对象有所修改,那么这样的拷贝开销就没有必 要.用代理延迟这一拷贝过程. 比如:我们有一个很大的 Collection,具体如 hashtable,有很多客户端会并发同时访问它.其中一个特别的客户端要进行连 续的数据获取,此时要求其他客户端不能再向 hashtable 中增加或删除 东东. 最直接的解决方案是:使用 collection 的 lock,让这特别的客户端获得这个 lock,进行连续的数据获取,然后再释放 lock. public void foFetches(Hashtable ht){ synchronized(ht){ //具体的连续数据获取动作.. } } 但是这一办法可能锁住 Collection 会很长时间,这段时间,其他客户端就不能访问该 Collection 了. 第二个解决方案是clone这个Collection,然后让连续的数据获取针对clone出来的那个Collection操作.这个方案前提是, 这个 Collection 是可 clone的,而且必须有提供深度 clone的方法.Hashtable 就提供了对自己的 clone方法,但不是 Key和 value对象的 clone,关于 Clone含义可以参考专门文章. public void foFetches(Hashtable ht){ Hashttable newht=(Hashtable)ht.clone(); } 问题又来了,由于是针对clone出来的对象操作,如果原来的母体被其他客户端操作修改了, 那么对clone出来的对象操作就 没有意义了. 最后解决方案:我们可以等其他客户端修改完成后再进行 clone,也就是说,这个特别的客户端先通过调用一个叫 clone的方 法来进行一系列数据获取操作.但实际上没有真正的进行对象拷贝,直至有其他客户端修改了这个对象 Collection. 使用 Proxy实现这个方案.这就是 copy-on-write操作. Proxy应用范围很广,现在流行的分布计算方式 RMI 和 Corba 等都是 Proxy模式的应用. 更多 Proxy应用,见 http://www.research.umbc.edu/~tarr/cs491/lectures/Proxy.pdf Sun 公司的 Explore the Dynamic Proxy API Dynamic Proxy Classes 设计模式之 Facade(外观 总管 Manager) Facade 模式的定义: 为子系统中的一组接口提供一个一致的界面. Facade一个典型应用就是数据库 JDBC 的应用,如下例对数据库的操作: public class DBCompare { Connection conn = null; PreparedStatement prep = null; ResultSet rset = null; try { Class.forName( "<driver>" ).newInstance(); conn = DriverManager.getConnection( "<database>" ); String sql = "SELECT * FROM <table> WHERE <column name> = ?"; prep = conn.prepareStatement( sql ); prep.setString( 1, "<column value>" ); rset = prep.executeQuery(); if( rset.next() ) { System.out.println( rset.getString( "<column name" ) ); } } catch( SException e ) { e.printStackTrace(); } finally { rset.close(); prep.close(); conn.close(); } } 上例是 Jsp 中最通常的对数据库操作办法. 在应用中,经常需要对数据库操作,每次都写上述一段代码肯定比较麻烦,需要将其中不变的部分提炼出来,做成一个接口,这 就引入了 facade 外观对象.如果以后我们更换 Class.forName 中的<driver>也非常方便,比如从 Mysql 数据库换到 Oracle 数据库,只要更换 facade接口中的 driver 就可以. 我们做成了一个 Facade 接口,使用该接口,上例中的程序就可以更改如下: public class DBCompare { String sql = "SELECT * FROM <table> WHERE <column name> = ?"; try { Mysql msql=new mysql(sql); prep.setString( 1, "<column value>" ); rset = prep.executeQuery(); if( rset.next() ) { System.out.println( rset.getString( "<column name" ) ); } } catch( SException e ) { e.printStackTrace(); } finally { mysql.close(); mysql=null; } } 可见非常简单,所有程序对数据库访问都是使用改接口,降低系统的复杂性,增加了灵活性. 如果我们要使用连接池,也只要针对 facade接口修改就可以. 由上图可以看出, facade实际上是个理顺系统间关系,降低系统间耦合度的一个常用的办法,也许你已经不知不觉在使用,尽 管不知道它就是 facade. 设计模式之 Composite(组合) Composite 模式定义: 将对象以树形结构组织起来,以达成“部分-整体” 的层次结构,使得客户端对单个对象和组合对象的使用具有一致性. Composite比较容易理解,想到 Composite 就应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象 的方法被调用执行时,Composite 将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一 动百来形容。 所以 Composite 模式使用到 Iterator 模式,和 Chain of Responsibility 模式类似。 Composite 好处: 1.使客户端调用简单,客户端可以一致的使用组合结构或其中单个对象,用户就不必关系自己处理的是单个对象还是整个 组合结构,这就简化了客户端代码。 2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。 如何使用 Composite? 首先定义一个接口或抽象类,这是设计模式通用方式了,其他设计模式对接口内部定义限制不多, Composite 却有个规定, 那就是要在接口内部定义一个用于访问和管理 Composite组合体的对象们(或称部件 Component). 下面的代码是以抽象类定义,一般尽量用接口 interface, public abstract class Equipment { private String name; //实价 public abstract double netPrice(); //折扣价格 public abstract double discountPrice(); //增加部件方法 public boolean add(Equipment equipment) { return false; } //删除部件方法 public boolean remove(Equipment equipment) { return false; } //注意这里,这里就提供一种用于访问组合体类的部件方法。 public Iterator iter() { return null; } public Equipment(final String name) { this.name=name; } } 抽象类 Equipment 就是 Component 定义,代表着组合体类的对象们,Equipment 中定义几个共同的方法。 public class Disk extends Equipment { public Disk(String name) { super(name); } //定义 Disk 实价为 1 public double netPrice() { return 1.; } //定义了 disk 折扣价格是 0.5 对折。 public double discountPrice() { return .5; } } Disk是组合体内的一个对象,或称一个部件,这个部件是个单独元素( Primitive)。 还有一种可能是,一个部件也是一个组合体,就是说这个部件下面还有'儿子',这是树形结构中通常的情况,应该比较容易理解。 现在我们先要定义这个组合体: abstract class CompositeEquipment extends Equipment { private int i=0; //定义一个 Vector 用来存放'儿子' private Lsit equipment=new ArrayList(); public CompositeEquipment(String name) { super(name); } public boolean add(Equipment equipment) { this.equipment.add(equipment); return true; } public double netPrice() { double netPrice=0.; Iterator iter=equipment.iterator(); for(iter.hasNext()) netPrice+=((Equipment)iter.next()).netPrice(); return netPrice; } public double discountPrice() { double discountPrice=0.; Iterator iter=equipment.iterator(); for(iter.hasNext()) discountPrice+=((Equipment)iter.next()).discountPrice(); return discountPrice; } //注意这里,这里就提供用于访问自己组合体内的部件方法。 //上面 dIsk 之所以没有,是因为 Disk 是个单独(Primitive)的元素. public Iterator iter() { return equipment.iterator() ; { //重载 Iterator 方法 public boolean hasNext() { return i<equipment.size(); } //重载 Iterator 方法 public Object next() { if(hasNext()) return equipment.elementAt(i++); else throw new NoSuchElementException(); } } 上面 CompositeEquipment 继承了 Equipment,同时为自己里面的对象们提供了外部访问的方法,重载了 Iterator,Iterator 是 Java 的 Collection 的一个接口,是 Iterator 模式的实现. 我们再看看 CompositeEquipment 的两个具体类:盘盒 Chassis 和箱子 Cabinet,箱子里面可以放很多东西,如底板, 电源盒,硬盘盒等;盘盒里面可以放一些小设备,如硬盘 软驱等。无疑这两个都是属于组合体性质的。 public class Chassis extends CompositeEquipment { public Chassis(String name) { super(name); } public double netPrice() { return 1.+super.netPrice(); } public double discountPrice() { return .5+super.discountPrice(); } } public class Cabinet extends CompositeEquipment { public Cabinet(String name) { super(name); } public double netPrice() { return 1.+super.netPrice(); } public double discountPrice() { return .5+super.discountPrice(); } } 至此我们完成了整个 Composite模式的架构。 我们可以看看客户端调用 Composote 代码: Cabinet cabinet=new Cabinet("Tower"); Chassis chassis=new Chassis("PC Chassis"); //将 PC Chassis 装到 Tower 中 (将盘盒装到箱子里) cabinet.add(chassis); //将一个 10GB 的硬盘装到 PC Chassis (将硬盘装到盘盒里) chassis.add(new Disk("10 GB")); //调用 netPrice()方法; System.out.println("netPrice="+cabinet.netPrice()); System.out.println("discountPrice="+cabinet.discountPrice()); 上面调用的方法 netPrice()或 discountPrice(),实际上 Composite 使用 Iterator 遍历了整个树形结构,寻找同样包含这 个方法的对象并实现调用执行. Composite是个很巧妙体现智慧的模式,在实际应用中,如果碰到树形结构,我们就可以尝试是否可以使用这个模式。 以论坛为例,一个版(forum)中有很多帖子(message),这些帖子有原始贴,有对原始贴的回应贴,是个典型的树形结构, 那么当然可以使用 Composite模式,那么我们进入 Jive中看看,是如何实现的. Jive 解剖 在 Jive中 ForumThread 是 ForumMessages 的容器 container(组合体).也就是说,ForumThread 类似我们上例中的 CompositeEquipment.它和 messages 的关系如图: [thread] |- [message] |- [message] |- [message] |- [message] |- [message] 我们在 ForumThread 看到如下代码: public interface ForumThread { .... public void addMessage(ForumMessage parentMessage, ForumMessage newMessage) throws UnauthorizedException; public void deleteMessage(ForumMessage message) throws UnauthorizedException; public Iterator messages(); .... } 类似 CompositeEquipment, 提供用于访问自己组合体内的部件方法: 增加 删除 遍历. 结合我的其他模式中对 Jive的分析,我们已经基本大体理解了 Jive 论坛体系的框架,如果你之前不理解设计模式,而直接去看 Jive源代码,你肯定无法看懂。 参考文章: Composite 模式和树形结构的讨论 设计模式之 Decorator(油漆工) 装饰模式:Decorator 常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的 对象我们称 decoratee.这两种实体在 Decorator 模式中是必须的. Decorator定义: 动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用 Decorator 模式相比用生成子类方式达到功能的扩充显得更为灵 活. 为什么使用 Decorator? 我们通常可以使用继承来实现功能的拓展,如果这些需要拓展的功能的种类很繁多,那么势必生成很多子类,增加系统的复杂性, 同时,使用继承实现功能拓展,我们必须可预见这些拓展功能,这些功能是编译时就确定了,是静态的. 使用Decorator的理由是:这些功能需要由用户动态决定加入的方式和时机.Decorator提供了"即插即用"的方法,在运行期间决 定何时增加何种功能. 如何使用? 举Adapter 中的打桩示例,在 Adapter 中有两种类:方形桩 圆形桩,Adapter模式展示如何综合使用这两个类,在Decorator模 式中,我们是要在打桩时增加一些额外功能,比如,挖坑 在桩上钉木板等,不关心如何使用两个不相关的类. 我们先建立一个接口: public interface Work { public void insert(); } 接口 Work有一个具体实现:插入方形桩或圆形桩,这两个区别对 Decorator 是无所谓.我们以插入方形桩为例: public class SquarePeg implements Work{ public void insert(){ System.out.println("方形桩插入"); } } 现在有一个应用:需要在桩打入前,挖坑,在打入后,在桩上钉木板,这些额外的功能是动态,可能随意增加调整修改,比如,可能又需 要在打桩之后钉架子(只是比喻). 那么我们使用 Decorator 模式,这里方形桩 SquarePeg 是 decoratee(被刷油漆者),我们需要在 decoratee 上刷些"油漆",这 些油漆就是那些额外的功能. public class Decorator implements Work{ private Work work; //额外增加的功能被打包在这个 List 中 private ArrayList others = new ArrayList(); //在构造器中使用组合 new方式,引入 Work 对象; public Decorator(Work work) { this.work=work; others.add("挖坑"); others.add("钉木板"); } public void insert(){ newMethod(); } //在新方法中,我们在 insert 之前增加其他方法,这里次序先后是用户灵活指定的 public void newMethod() { otherMethod(); work.insert(); } public void otherMethod() { ListIterator listIterator = others.listIterator(); while (listIterator.hasNext()) { System.out.println(((String)(listIterator.next())) + " 正在进行"); } } } 在上例中,我们把挖坑和钉木板都排在了打桩 insert 前面,这里只是举例说明额外功能次序可以任意安排. 好了,Decorator 模式出来了,我们看如何调用: Work squarePeg = new SquarePeg(); Work decorator = new Decorator(squarePeg); decorator.insert(); Decorator 模式至此完成. 如果你细心,会发现,上面调用类似我们读取文件时的调用: FileReader fr = new FileReader(filename); BufferedReader br = new BufferedReader(fr); 实际上 Java 的 I/O API 就是使用 Decorator 实现的,I/O变种很多,如果都采取继承方法,将会产生很多子类,显然相当繁琐. Jive 中的 Decorator 实现 在论坛系统中,有些特别的字是不能出现在论坛中如"打倒 XXX",我们需要过滤这些"反动"的字体.不让他们出现或者高亮度显 示. 在 IBM Java 专栏中专门谈 Jive的文章中,有谈及 Jive中 ForumMessageFilter.java 使用了 Decorator 模式,其实,该程序并 没有真正使用 Decorator,而是提示说:针对特别论坛可以设计额外增加的过滤功能,那么就可以重组 ForumMessageFilter 作 为 Decorator 模式了. 所以,我们在分辨是否真正是Decorator模式,以及会真正使用Decorator模式,一定要把握好Decorator模式的定义,以及其中 参与的角色(Decoratee 和 Decorator). 设计模式之 Bridge Bridge 模式定义 :将抽象和行为划分开来,各自独立,但能动态的结合。 任何事物对象都有抽象和行为之分,例如人,人是一种抽象,人分男人和女人等;人有行为,行为也有各种具体表现,所 以,“人”与“人的行为”两个概念也反映了抽象和行为之分。 在面向对象设计的基本概念中,对象这个概念实际是由属性和行为两个部分组成的,属性我们可以认为是一种静止的,是 一种抽象,一般情况下,行为是包含在一个对象中,但是,在有的情况下,我们需要将这些行为也进行归类,形成一个总的行 为接口,这就是桥模式的用处。 为什么使用? 不希望抽象部分和行为有一种固定的绑定关系,而是应该可以动态联系的。 如果一个抽象类或接口有多个具体实现(子类、concrete subclass),这些子类之间关系可能有以下两种情况: 1. 这多个子类之间概念是并列的,如前面举例,打桩,有两个 concrete class:方形桩和圆形桩;这两个形状上的桩是并列的, 没有概念上的重复。 2.这多个子类之中有内容概念上重叠.那么需要我们把抽象共同部分和行为共同部分各自独立开来,原来是准备放在一个接 口里,现在需要设计两个接口:抽象接口和行为接口,分别放置抽象和行为. 例如,一杯咖啡为例,子类实现类为四个:中杯加奶、大杯加奶、 中杯不加奶、大杯不加奶。 但是,我们注意到:上面四个子类中有概念重叠,可从另外一个角度进行考虑,这四个类实际是两个角色的组合:抽象 和 行为,其中抽象为:中杯和大杯;行为为:加奶 不加奶(如加橙汁 加苹果汁). 实现四个子类在抽象和行为之间发生了固定的绑定关系,如果以后动态增加加葡萄汁的行为,就必须再增加两个类:中杯 加葡萄汁和大杯加葡萄汁。显然混乱,扩展性极差。 那我们从分离抽象和行为的角度,使用 Bridge模式来实现。 如何实现?

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值