设计模式的三个分类
-
创建型模式(5):对象实例化的模式,创建型模式用于解耦对象的实例化过程。
-
结构型模式(7):把类或对象结合在一起形成一个更大的结构。
-
行为型模式(11):类和对象如何交互,及划分责任和算法。
其实还有两类:
- 并发型模式
- 线程池模式
用一个图片来整体描述一下:
上一篇文章主要说明了创建型模式。下面继续说明结构型模式
结构型模式模式的关键点
结构型模式主要用于处理类和对象的组合
范围 | 模式 | 特点 |
---|---|---|
类模式 | (类)适配器模式 | 将一个类的方法接口转换成客户希望的另外一个接口。 |
对象模式 | (对象)适配器模式 | 创建新类持源类的新适配实例。 |
对象模式 | 桥接模式 | 将抽象部分和它的实现部分分离,使它们都可以独立的变化。 |
对象模式 | 组合模式 | 将对象组合成树形结构以表示“”部分-整体“”的层次结构。 |
对象模式 | 装饰者模式 | 动态的给对象添加新的功能。 |
对象模式 | 外观模式 | 对外提供一个统一的方法,来访问子系统中的一群接口。 |
对象模式 | 亨元模式 | 通过共享技术来有效的支持大量细粒度的对象。 |
对象模式 | 代理模式 | 为其他对象提供一个代理以便控制这个对象的访问。 |
概说结构型设计模式
适配器模式
在我们的应用程序中我们可能需要将两个不同接口的类来进行通信,在不修改这两个的前提下我们可能会需要某个中间件来完成这个衔接的过程。这个中间件就是适配器。所谓适配器模式就是将一个类的接口,转换成客户期望的另一个接口。它可以让原本两个不兼容的接口能够无缝完成对接。
作为中间件的适配器将目标类和适配者解耦,增加了类的透明性和可复用性。
模式结构
适配器模式包含如下角色:
- Target:目标抽象类
- Adapter:适配器类
- Adaptee:适配者类
- Client:客户类
适配器模式的作用就是在原来的类上提供新功能。主要可分为3种:
- 类适配:创建新类,继承源类,并实现新接口
class adapter extends oldClass implements newFunc{}
- 对象适配:创建新类持源类的实例,并实现新接口
class adapter implements newFunc {
private oldClass oldInstance;
}
- 接口适配:创建新的抽象类实现旧接口方法
abstract class adapter implements oldClassFunc {
void newFunc();
}
总结
意图:将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
主要解决:主要解决在软件系统中,常常要将一些"现存的对象"放到新的环境中,而新环境要求的接口是现对象不能满足的。
何时使用:
- 系统需要使用现有的类,而此类的接口不符合系统的需要。
- 想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作,这些源类不一定有一致的接口。
- 通过接口转换,将一个类插入另一个类系中。(比如老虎和飞禽,现在多了一个飞虎,在不增加实体的需求下,增加一个适配器,在里面包容一个虎对象,实现飞的接口。)
如何解决:继承或依赖(推荐)。
关键代码:适配器继承或依赖已有的对象,实现想要的目标接口。
应用实例:
- 美国电器 110V,中国 220V,就要有一个适配器将 110V 转化为 220V。
- JAVA JDK 1.1 提供了 Enumeration 接口,而在 1.2 中提供了 Iterator 接口,想要使用 1.2 的 JDK,则要将以前系统的 Enumeration 接口转化为 Iterator 接口,这时就需要适配器模式。
- 在 LINUX 上运行 WINDOWS 程序。
- JAVA 中的 jdbc。
优点:
- 可以让任何两个没有关联的类一起运行。
- 提高了类的复用。
- 增加了类的透明度。
- 灵活性好。
缺点:
- 过多地使用适配器,会让系统非常零乱,不易整体进行把握。比如,明明看到调用的是 A 接口,其实内部被适配成了 B 接口的实现,一个系统如果太多出现这种情况,无异于一场灾难。因此如果不是很有必要,可以不使用适配器,而是直接对系统进行重构。
- 由于 JAVA 至多继承一个类,所以至多只能适配一个适配者类,而且目标类必须是抽象类。
使用场景:有动机地修改一个正常运行的系统的接口,这时应该考虑使用适配器模式。
注意事项:适配器不是在详细设计时添加的,而是解决正在服役的项目的问题。
桥接模式
如果说某个系统能够从多个角度来进行分类,且每一种分类都可能会变化,那么我们需要做的就是讲这多个角度分离出来,使得他们能独立变化,减少他们之间的耦合,这个分离过程就使用了桥接模式。所谓桥接模式就是讲抽象部分和实现部分隔离开来,使得他们能够独立变化。
桥接模式将继承关系转化成关联关系,封装了变化,完成了解耦,减少了系统中类的数量,也减少了代码量。
模式结构
桥接模式包含如下角色:
- Abstraction:抽象类
- RefinedAbstraction:扩充抽象类
- Implementor:实现类接口
- ConcreteImplementor:具体实现类
/**
* 定义Implementor(手机内存接口)
*/
public interface Memory {
public void addMemory();
}
//定义ConcreteImplementor(具体内存)
public class Memory6G implements Memory {
@Override
public void addMemory() {
System.out.println("安装了6G内存");
}
}
public class Memory8G implements Memory {
@Override
public void addMemory() {
System.out.println("安装了8G内存");
}
}
/**
* 定义Abstraction(手机抽象类)
*/
public abstract class Phone {
public Memory phoneMemory;
public void setMemory(Memory memory) {
this.phoneMemory = memory;
}
public abstract void buyPhone();
}
//定义RefinedAbstraction(具体手机品牌)
public class Huawei extends Phone {
@Override
public void buyPhone() {
//memory是继承自父类调用的setMemory中的方法
phoneMemory.addMemory();
System.out.println("购买华为手机");
}
}
public class Mi extends Phone {
@Override
public void buyPhone() {
//memory是继承自父类调用的setMemory中的方法
phoneMemory.addMemory();
System.out.println("购买小米手机");
}
}
public class Client {
public static void main(String[] args) {
//让华为搭配8G内存
Phone huawei = new Huawei();
huawei.setMemory(new Memory8G());
huawei.buyPhone();
//让小米搭配6G内存
Phone mi = new Mi();
mi.setMemory(new Memory6G());
mi.buyPhone();
}
}
//--output--
//安装了8G内存
//购买华为手机
//安装了6G内存
//购买小米手机
使用了桥接模式之后,我们的两个维度就像桥梁一样被链接了起来。体现了松耦合的特性。
总结
意图:将抽象部分与实现部分分离,使它们都可以独立的变化。
主要解决:在有多种可能会变化的情况下,用继承会造成类爆炸问题,扩展起来不灵活。
何时使用:实现系统可能有多个角度分类,每一种角度都可能变化。
如何解决:把这种多角度分类分离出来,让它们独立变化,减少它们之间耦合。
关键代码:抽象类依赖实现类。
应用实例:
- 猪八戒从天蓬元帅转世投胎到猪,转世投胎的机制将尘世划分为两个等级,即:灵魂和肉体,前者相当于抽象化,后者相当于实现化。生灵通过功能的委派,调用肉体对象的功能,使得生灵可以动态地选择。
- 墙上的开关,可以看到的开关是抽象的,不用管里面具体怎么实现的。
优点:
- 抽象和实现的分离。
- 优秀的扩展能力。
- 实现细节对客户透明。
缺点:
- 桥接模式的引入会增加系统的理解与设计难度,由于聚合关联关系建立在抽象层,要求开发者针对抽象进行设计与编程。
使用场景:
- 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系,通过桥接模式可以使它们在抽象层建立一个关联关系。
- 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统,桥接模式尤为适用。
- 一个类存在两个独立变化的维度,且这两个维度都需要进行扩展。
注意事项:对于两个独立变化的维度,使用桥接模式再适合不过了。
组合模式
组合模式组合多个对象形成树形结构以表示“整体-部分”的结构层次。它定义了如何将容器对象和叶子对象进行递归组合,使得客户在使用的过程中无须进行区分,可以对他们进行一致的处理。在使用组合模式中需要注意一点也是组合模式最关键的地方:叶子对象和组合对象实现相同的接口。这就是组合模式能够将叶子节点和对象节点进行一致处理的原因。
虽然组合模式能够清晰地定义分层次的复杂对象,也使得增加新构件也更容易,但是这样就导致了系统的设计变得更加抽象,如果系统的业务规则比较复杂的话,使用组合模式就有一定的挑战了。
模式结构
组合模式包含如下角色:
- Component: 抽象构件
- Leaf: 叶子构件
- Composite: 容器构件
- Client: 客户类
/**
* 定义组合部件(学校接口)
*/
public interface School {
void addPart(School company);
void removePart(School company);
void displayPart();
//不同部门所具有的各自的职责
void action();
}
/**
* 定义合成部件(具体学校)
*/
public class ConcreteSchool implements School {
private List<School> partList = new ArrayList<>();
private String name;
public ConcreteSchool(String name) { this.name = name;}
@Override
public void addPart(School school) { partList.add(school); }
@Override
public void removePart(School school) { partList.remove(school); }
@Override
public void displayPart() {
for (School school : partList) {
school.displayPart();
}
}
//每一个部门还可以做自己的事情
@Override
public void action() {
for (School part : partList) {
part.action();
}
}
}
/**
* 定义叶子(这里定义两个部门:网络部和安全部)
*/
//网络部门
public class InternetDepartment implements School {
private String name;
public InternetDepartment(String name) { this.name = name; }
@Override
public void addPart(School company) { }
@Override
public void removePart(School company) { }
@Override
public void displayPart() { }
@Override
public void action() {
System.out.println("我是" + name + ",负责学校的网络管理");
}
}
//安全部门
public class SecurityDepartment implements School {
private String name;
public SecurityDepartment(String name) { this.name = name; }
@Override
public void addPart(School company) { }
@Override
public void removePart(School company) { }
@Override
public void displayPart() { }
@Override
public void action() {
System.out.println("我是" + name + ",负责学校的安全工作");
}
}
public class Test {
public static void main(String[] args) {
//总校部门
ConcreteSchool rootSchool = new ConcreteSchool("总校");
rootSchool.addPart(new InternetDepartment("总校网络部"));
rootSchool.addPart(new SecurityDepartment("总校保卫部"));
//分校部门
ConcreteSchool branchSchool = new ConcreteSchool("分校");
branchSchool.addPart(new InternetDepartment("分校网络部"));
branchSchool.addPart(new SecurityDepartment("分校保卫部"));
rootSchool.addPart(branchSchool);
rootSchool.displayPart();
rootSchool.action();
}
//我是总校网络部,负责学校的安全工作
//我是总校保卫部,负责学校的安全工作
//我是分校网络部,负责学校的安全工作
//我是分校保卫部,负责学校的安全工作
}
我们看到我们只要三个类就可以任意往下继续拓展,有了新部门也只需要增加一个新的部门类即可。
总结
意图:将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
主要解决:它在我们树型结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以像处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。
何时使用:
- 您想表示对象的部分-整体层次结构(树形结构)。
- 您希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
如何解决:树枝和叶子实现统一接口,树枝内部组合该接口。
关键代码:树枝内部组合该接口,并且含有内部属性 List,里面放 Component。
应用实例:
- 算术表达式包括操作数、操作符和另一个操作数,其中,另一个操作符也可以是操作数、操作符和另一个操作数。
- 在 JAVA AWT 和 SWING 中,对于 Button 和 Checkbox 是树叶,Container 是树枝。
优点:
- 高层模块调用简单。
- 节点自由增加。
缺点:在使用组合模式时,其叶子和树枝的声明都是实现类,而不是接口,违反了依赖倒置原则。
使用场景:部分、整体场景,如树形菜单,文件、文件夹的管理。
注意事项:定义时为具体类。
装饰者模式
我们可以通过继承和组合的方式来给一个对象添加行为,虽然使用继承能够很好拥有父类的行为。
但是它存在几个缺陷:
- 对象之间的关系复杂的话,系统变得复杂不利于维护。
- 容易产生“类爆炸”现象。
- 是静态的。在这里我们可以通过使用装饰者模式来解决这个问题。
装饰者模式,动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更加有弹性的替代方案。
虽然装饰者模式能够动态将责任附加到对象上,但是他会产生许多的细小对象,增加了系统的复杂度。
模式结构
装饰模式包含如下角色:
- Component: 抽象构件
- ConcreteComponent: 具体构件
- Decorator: 抽象装饰类
- ConcreteDecorator: 具体装饰类
/**
* 定义奶茶接口( Component )
*/
public interface MilkTea {
public String milkTeaName();
public int milkTeaPrice();
}
/**
* 定义珍珠奶茶( ConcreteComponent )
*/
public class PearlMilkTea implements MilkTea {
@Override
public String milkTeaName() {
return "珍珠奶茶";
}
@Override
public int milkTeaPrice() {
//一杯珍珠奶茶15块
return 15;
}
}
/**
* 定义珍珠奶茶( ConcreteComponent )
*/
public class HoneyMilkTea implements MilkTea {
@Override
public String milkTeaName() {
return "蜂蜜奶茶";
}
@Override
public int milkTeaPrice() {
//一杯蜂蜜奶茶20块
return 20;
}
}
/**
* 定义口味( Decorator)
*/
public class Taste implements MilkTea {
@Override
public String milkTeaName() {
return "具体的名字让之类去定义";
}
@Override
public int milkTeaPrice() {
return 0;
}
}
/**
* 具体口味(ConcreteDecorator):加冰
*/
public class AddIceTaste extends Taste {
private String description = "+奶茶加冰。。。";
private MilkTea milkTea;
//构造参数传入需要加工的对象
public AddIceTaste(MilkTea milkTea) {
this.milkTea = milkTea;
}
//让相应奶茶去增加这个口味
public String milkTeaName() {
return milkTea.milkTeaName() + description;
}
//加冰后价格增加5元
public int milkTeaPrice() {
return milkTea.milkTeaPrice() + 5;
}
}
/**
* 具体口味(ConcreteDecorator):加咖啡
*/
public class AddCoffeeTaste extends Taste {
private String description = "+奶茶加咖啡。。。";
private MilkTea milkTea;
//构造参数传入需要加工的对象
public AddCoffeeTaste(MilkTea milkTea) {
this.milkTea = milkTea;
}
//让相应奶茶去增加这个口味
public String milkTeaName() {
return milkTea.milkTeaName() + description;
}
//加咖啡后价格增加15元
public int milkTeaPrice() {
return milkTea.milkTeaPrice() + 15;
}
}
public class User{
/**
* 用户购买奶茶
* @param args
*/
public static void main(String[] args) {
MilkTea honeyMilkTea = new HoneyMilkTea();
System.out.println("买了杯蜂蜜奶茶,价格是" + honeyMilkTea.milkTeaPrice());
honeyMilkTea = new AddCoffeeTaste(honeyMilkTea);
System.out.println("加咖啡,价格是" + honeyMilkTea.milkTeaPrice());
MilkTea pearMilkTea = new PearlMilkTea();
System.out.println("买了一杯珍珠奶茶,价格是" + pearMilkTea.milkTeaPrice());
pearMilkTea = new AddIceTaste(pearMilkTea);
System.out.println("加冰块,价格是" + pearMilkTea.milkTeaPrice());
}
//买了杯蜂蜜奶茶,价格是20
//加咖啡,价格是35
//买了一杯珍珠奶茶,价格是15
//加冰块,价格是20
}
- 装饰模式用于动态地给一个对象增加一些额外的职责,是一种对象结构型模式。
- 装饰模式包含四个角色。
- 比生成子类实现更为灵活。
- 装饰模式可分为透明装饰模式和半透明装饰模式。
总结
意图:动态地给一个对象添加一些额外的职责。就增加功能来说,装饰器模式相比生成子类更为灵活。
主要解决:一般的,我们为了扩展一个类经常使用继承方式实现,由于继承为类引入静态特征,并且随着扩展功能的增多,子类会很膨胀。
何时使用:在不想增加很多子类的情况下扩展类。
如何解决:将具体功能职责划分,同时继承装饰者模式。
关键代码:
- Component 类充当抽象角色,不应该具体实现。
- 修饰类引用和继承 Component 类,具体扩展类重写父类方法。
应用实例:
- 孙悟空有 72 变,当他变成"庙宇"后,他的根本还是一只猴子,但是他又有了庙宇的功能。
- 不论一幅画有没有画框都可以挂在墙上,但是通常都是有画框的,并且实际上是画框被挂在墙上。在挂在墙上之前,画可以被蒙上玻璃,装到框子里;这时画、玻璃和画框形成了一个物体。
优点:装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能。
缺点:多层装饰比较复杂。
使用场景:
- 扩展一个类的功能。
- 动态增加功能,动态撤销。
注意事项:可代替继承。
外观模式
我们都知道类与类之间的耦合越低,那么可复用性就越好,如果两个类不必彼此通信,那么就不要让这两个类发生直接的相互关系,如果需要调用里面的方法,可以通过第三者来转发调用。
外观模式非常好的诠释了这段话。外观模式提供了一个统一的接口,用来访问子系统中的一群接口。它让一个应用程序中子系统间的相互依赖关系减少到了最少,它给子系统提供了一个简单、单一的屏障,客户通过这个屏障来与子系统进行通信。
通过使用外观模式,使得客户对子系统的引用变得简单了,实现了客户与子系统之间的松耦合。但是它违背了“开闭原则”,因为增加新的子系统可能需要修改外观类或客户端的源代码。
模式结构
- Facade: 外观角色
- SubSystem:子系统角色
public class CPU {
public void startup(){
System.out.println("cpu startup!");
}
public void shutdown(){
System.out.println("cpu shutdown!");
}
}
public class Disk {
public void startup(){
System.out.println("disk startup!");
}
public void shutdown(){
System.out.println("disk shutdown!");
}
}
public class Memory {
public void startup(){
System.out.println("memory startup!");
}
public void shutdown(){
System.out.println("memory shutdown!");
}
}
/**
* 外观类:给客户端提供了一个视图
*/
public class ComputerFacade {
private CPU cpu = new CPU();
private Memory memory = new Memory();
private Disk disk = new Disk();
/**
* 开机一步到位,用户不必根各个硬件打交道,就像一个开关搞定
*/
public void startup(){
System.out.println("start the computer!");
cpu.startup();
memory.startup();
disk.startup();
System.out.println("start computer finished!");
}
public void shutdown(){
System.out.println("begin to close the computer!");
cpu.shutdown();
memory.shutdown();
disk.shutdown();
System.out.println("computer closed!");
}
}
这是我们平时开发用的最多的模式之一,可以说我们每天都在用这个模式在写代码,只是我们可能没有意识到。
根据 "单一职责原则" ,在软件中将一个系统划分为若干个子系统有利于降低系统的复杂性,一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小,而达到该目标的途径之一就是引入一个外观对象,它为子系统的访问提供了一个简单而单一的入口。
外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行,外观类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与外观对象打交道,而不需要与子系统内部的很多对象打交道。 外观模式的目的在于降低系统的复杂程度。 外观模式从很大程度上提高了客户端使用的便捷性,使得客户端无须关心子系统的工作细节,通过外观角色即可调用相关功能。
总结
意图:为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
主要解决:降低访问复杂系统的内部子系统时的复杂度,简化客户端与之的接口。
何时使用:
- 客户端不需要知道系统内部的复杂联系,整个系统只需提供一个"接待员"即可。
- 定义系统的入口。
如何解决:客户端不与系统耦合,外观类与系统耦合。
关键代码:在客户端和复杂系统之间再加一层,这一层将调用顺序、依赖关系等处理好。
应用实例:
- 去医院看病,可能要去挂号、门诊、划价、取药,让患者或患者家属觉得很复杂,如果有提供接待人员,只让接待人员来处理,就很方便。
- JAVA 的三层开发模式。
优点:
- 减少系统相互依赖。
- 提高灵活性。
- 提高了安全性。
缺点:不符合开闭原则,如果要改东西很麻烦,继承重写都不合适。
使用场景:
- 为复杂的模块或子系统提供外界访问的模块。
- 子系统相对独立。
- 预防低水平人员带来的风险。
注意事项:在层次化结构中,可以使用外观模式定义系统中每一层的入口。
亨元模式
在一个系统中对象会使得内存占用过多,特别是那些大量重复的对象,这就是对系统资源的极大浪费。享元模式对对象的重用提供了一种解决方案,它使用共享技术对相同或者相似对象实现重用。享元模式就是运行共享技术有效地支持大量细粒度对象的复用。系统使用少量对象,而且这些都比较相似,状态变化小,可以实现对象的多次复用。这里有一点要注意:享元模式要求能够共享的对象必须是细粒度对象。享元模式通过共享技术使得系统中的对象个数大大减少了,同时享元模式使用了内部状态和外部状态,同时外部状态相对独立,不会影响到内部状态,所以享元模式能够使得享元对象在不同的环境下被共享。同时正是分为了内部状态和外部状态,享元模式会使得系统变得更加复杂,同时也会导致读取外部状态所消耗的时间过长。
模式结构
享元模式包含如下角色:
- Flyweight: 抽象享元类
- ConcreteFlyweight: 具体享元类
- UnsharedConcreteFlyweight: 非共享具体享元类
- FlyweightFactory: 享元工厂类
/**
* Flyweight抽象类
* 所有具体享元类的超类或接口,通过这个接口,Flyweight可以接受并作用于外部状态
*/
public abstract class Flyweight {
//内部状态
public String intrinsic;
//外部状态
protected final String extrinsic;
//要求享元角色必须接受外部状态
public Flyweight(String extrinsic) {
this.extrinsic = extrinsic;
}
//定义业务操作
public abstract void operate(int extrinsic);
public String getIntrinsic() {
return intrinsic;
}
public void setIntrinsic(String intrinsic) {
this.intrinsic = intrinsic;
}
}
/**
* ConcreteFlyweight类
* 继承Flyweight超类或实现Flyweight接口,并为其内部状态增加存储空间
*/
public class ConcreteFlyweight extends Flyweight {
//接受外部状态
public ConcreteFlyweight(String extrinsic) {
super(extrinsic);
}
//根据外部状态进行逻辑处理
@Override
public void operate(int extrinsic) {
System.out.println("具体Flyweight:" + extrinsic);
}
}
/**
* UnsharedConcreteFlyweight类
* 指那些不需要共享的Flyweight子类
*/
public class UnsharedConcreteFlyweight extends Flyweight {
public UnsharedConcreteFlyweight(String extrinsic) {
super(extrinsic);
}
@Override
public void operate(int extrinsic) {
System.out.println("不共享的具体Flyweight:" + extrinsic);
}
}
/**
* FlyweightFactory类
* 一个享元工厂,用来创建并管理Flyweight对象,主要是用来确保合理地共享Flyweight。
* 当用户请求一个Flyweight时,FlyweightFactory对象提供一个已创建的实例或创建一个实例。
*/
public class FlyweightFactory {
//定义一个池容器
private static HashMap<String, Flyweight> pool = new HashMap<>();
//享元工厂
public static Flyweight getFlyweight(String extrinsic) {
Flyweight flyweight = null;
if(pool.containsKey(extrinsic)) { //池中有该对象
flyweight = pool.get(extrinsic);
System.out.print("已有 " + extrinsic + " 直接从池中取---->");
} else {
//根据外部状态创建享元对象
flyweight = new ConcreteFlyweight(extrinsic);
//放入池中
pool.put(extrinsic, flyweight);
System.out.print("创建 " + extrinsic + " 并从池中取出---->");
}
return flyweight;
}
}
/**
* Client客户端
*/
public class Client {
public static void main(String[] args) {
int extrinsic = 22;
Flyweight flyweightX = FlyweightFactory.getFlyweight("X");
flyweightX.operate(++ extrinsic);
Flyweight flyweightY = FlyweightFactory.getFlyweight("Y");
flyweightY.operate(++ extrinsic);
Flyweight flyweightZ = FlyweightFactory.getFlyweight("Z");
flyweightZ.operate(++ extrinsic);
Flyweight flyweightReX = FlyweightFactory.getFlyweight("X");
flyweightReX.operate(++ extrinsic);
Flyweight unsharedFlyweight = new UnsharedConcreteFlyweight("X");
unsharedFlyweight.operate(++ extrinsic);
}
// 运行结果:
// 创建X 并从池中取出---->具体Flyweight:23
// 创建Y 并从池中取出---->具体Flyweight:24
// 创建Z 并从池中取出---->具体Flyweight:25
// 已有X 直接从池中取---->具体Flyweight:26
// 不共享的具体Flyweight:27
}
上面享元模式的定义为我们提出了两个要求:细粒度和共享对象。我们知道分配太多的对象到应用程序中将有损程序的性能,同时还容易造成内存溢出,要避免这种情况,用到的就是共享技术,这里就需要提到内部状态和外部状态了。
因为要求细粒度对象,所以不可避免地会使对象数量多且性质相近,此时我们就将这些对象的信息分为两个部分:内部状态和外部状态。
内部状态指对象共享出来的信息,存储在享元对象内部并且不会随环境的改变而改变;外部状态指对象得以依赖的一个标记,是随环境改变而改变的、不可共享的状态。
所以外部状态必须由客户端保存,并且在享元对象被创建之后,在需要使用的时候,传递到享元对象的内部,外部状态之间是相互独立的。
举个栗子:围棋中有大量的棋子对象,颜色和位置坐标组合起来各个对象都不一样,但是无论如何也只有黑白两色,所以棋子颜色就是棋子的内部状态;而各个棋子之间的差别就是位置的不同,我们落子嘛,落子颜色是定的,但位置是变化的,所以方位坐标就是棋子的外部状态。
如果用享元模式来处理棋子,那么棋子对象就可以减少到只有两个实例,这样就很好的解决了对象的开销问题。
总结
意图:运用共享技术有效地支持大量细粒度的对象。
主要解决:在有大量对象时,有可能会造成内存溢出,我们把其中共同的部分抽象出来,如果有相同的业务请求,直接返回在内存中已有的对象,避免重新创建。
何时使用:
- 系统中有大量对象。
- 这些对象消耗大量内存。
- 这些对象的状态大部分可以外部化。
- 这些对象可以按照内蕴状态分为很多组,当把外蕴对象从对象中剔除出来时,每一组对象都可以用一个对象来代替。
- 系统不依赖于这些对象身份,这些对象是不可分辨的。
如何解决:用唯一标识码判断,如果在内存中有,则返回这个唯一标识码所标识的对象。
关键代码:用 HashMap 存储这些对象。
应用实例:
- JAVA 中的 String,如果有则返回,如果没有则创建一个字符串保存在字符串缓存池里面。
- 数据库的数据池。
优点:大大减少对象的创建,降低系统的内存,使效率提高。
缺点:提高了系统的复杂度,需要分离出外部状态和内部状态,而且外部状态具有固有化的性质,不应该随着内部状态的变化而变化,否则会造成系统的混乱。
使用场景:
- 系统有大量相似对象。
- 需要缓冲池的场景。
注意事项:
- 注意划分外部状态和内部状态,否则可能会引起线程安全问题。
- 这些类必须有一个工厂对象加以控制。
代理模式
代理模式就是给一个对象提供一个代理,并由代理对象控制对原对象的引用。它使得客户不能直接与真正的目标对象通信。代理对象是目标对象的代表,其他需要与这个目标对象打交道的操作都是和这个代理对象在交涉。
代理对象可以在客户端和目标对象之间起到中介的作用,这样起到了的作用和保护了目标对象的,同时也在一定程度上面减少了系统的耦合度。
模式结构
- Subject:抽象主题角色
- Proxy:代理主题角色
- RealSubject:真实主题角色
一定有人会问,这个类图和Adaptor (适配器模式) 很像啊。没错,Proxy和Adaptor的实现代码上几乎是一样的,但它们之间最大的不同在于面向对象的设计的意义上,Proxy在很多时候对于Client其实是完全不感知的。而Adaptor,对于Client而言,却是可知的,因为Adaptor引入了新的类型。
或者再换一种说法,Adaptor所要解决的问题是适配,它的目的在于接口的转换。而Proxy恰恰相反,它的目的在于保持接口不变,而改变接口定义的方法的行为。
一句话总结代理模式,适配器模式,装饰者模式的区别:
适配器模式主要解决接口转换的问题,代理模式主要解决对象无法直接访问的问题,装饰者模式主要用来增强功能。
代理模式也分为三种类型代理形式:
静态代理
在使用静态代理时,被代理对象与代理对象需要一起实现相同的接口或者是继承相同父类,因此要定义一个接口或抽象类.
/**
* 抽象接口
*/
interface IStar {
void sing();
}
/**
* 真实对象
*/
class LDHStar implements IStar {
@Override
public void sing() {
System.out.println("刘德华唱歌");
}
}
/**
* 代理类需要有真实对象的控制权 (引用)
*/
class ProxyManger implements IStar {
// 真实对象的引用
private IStar star;
public ProxyManger() {
super();
}
public ProxyManger(IStar star) {
super();
this.star = star;
}
@Override
public void sing() {
System.out.println("唱歌前准备");
star.sing();
System.out.println("善后工作");
}
}
class Test{
public static void main(String[] args) {
// 创建明星对象
IStar ldh = new LDHStar();
ProxyManger proxy = new ProxyManger(ldh);
proxy.sing();
}
// 运行结果:
// 唱歌前准备
// 刘德华唱歌
// 善后工作
}
静态代理总结:
- 优点:可以做到在不修改目标对象的功能前提下,对目标功能扩展
- 缺点:因为代理对象需要与目标对象实现一样的接口,所以会有很多代理类,类太多.同时,一旦接口增加方法,目标对象与代理对象都要维护.
而动态代理方式可以解决上面的问题
动态代理
动态代理的主要特点就是能够在程序运行时JVM才为被代理对象生成代理对象。
常说的动态代理也叫做JDK代理也是一种接口代理,JDK中生成代理对象的代理类就是Proxy,所在包是 java.lang.reflect
/**
* 目标类接口
*/
interface IDog{
void run();
}
/**
* 目标类
*/
class GunDog implements IDog{
@Override
public void run() {
System.out.println("猎狗在跑");
}
}
class DogUtils{
public static void method1() {
System.out.println("增强方式一");
}
public static void method2() {
System.out.println("增强方式二");
}
}
/**
* InvocationHandler接口是proxy代理实例的调用处理程序实现的一个接口,
* 每一个proxy代理实例都有一个关联的调用处理程序;
* 在代理实例调用方法时,方法调用被编码分派到调用处理程序的invoke方法。
*/
class MyInvocationHandle implements InvocationHandler{
private Object target;
public void setTarget(Object target) {
this.target = target;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
DogUtils.method1();
method.invoke(target, args);
DogUtils.method2();
return null;
}
}
/**
* 生产代理对象的工厂
*/
class MyProxyFactory{
public static Object getProxy(Object target) {
MyInvocationHandle handle = new MyInvocationHandle();
handle.setTarget(target);
Object proxy = Proxy.newProxyInstance(target.getClass().getClassLoader(), target.getClass().getInterfaces(), handle);
return proxy;
}
}
public class ProxyDemo {
public static void main(String[] args) {
IDog dog = new GunDog();
IDog proxy =(IDog) MyProxyFactory.getProxy(dog);
proxy.run();
}
// 运行结果:
// 增强方式一
// 猎狗在跑
// 增强方式二
}
动态代理总结:
代理对象不需要实现接口,但是目标对象一定要实现接口,否则不能使用动态代理,因此这也算是这种方式的缺陷。
Cglib代理
上面的静态代理和动态代理模式有个相同点就是都要求目标对象是实现一个接口的对象,然而并不是任何对象都会实现一个接口,也存在没有实现任何的接口的对象。
这时就可以使用继承目标类以目标对象子类的方式实现代理,这种方法就叫做:Cglib代理,也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能的扩展。
使用JDK动态代理有一个限制,就是被代理的对象必须实现一个或多个接口,若想代理没有实现接口的类,就需要使用Cglib实现。
由于Cglib是第三方提供的所以使用的时候需要导入相关的jar包,有两个包:
- cglib-x.x.x.jar
- asm-x.x.x.jar
class ArraySort2{
public void quickSort(int[] arr) {
Arrays.sort(arr);
}
public void selectSort(int[] arr) {
for (int i = 0; i < arr.length; i++) {
for (int j = i+1; j < arr.length; j++) {
if (arr[i] > arr[j]) {
int temp = 0;
temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
}
}
}
}
public void bubbleSort(int[] arr) {
for (int i = 0; i < arr.length - 1; i++) {
for (int j = 0; j < arr.length - 1 - i; j++) {
if (arr[j] > arr[j + 1]) {
int temp = 0;
temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
}
}
}
}
}
public class CglibProxy {
public static void main(String[] args) {
int[] arr = new int[100000];
for (int i = 0; i < arr.length; i++) {
arr[i] = (int) (Math.random() * 1000);
}
//实例化一个增强器,也就是cglib中的一个class generator
Enhancer enhancer = new Enhancer();
//设置目标类
enhancer.setSuperclass(ArraySort2.class);
//设置拦截对象,这里直接使用匿名内部类写法
enhancer.setCallback(new MethodInterceptor() {
@Override
public Object intercept(Object object , Method method, Object[] args, MethodProxy proxy) throws Throwable {
String sortName = method.getName();
switch (sortName) {
case "bubbleSort":
sortName = "冒泡排序";
break;
case "selectSort":
sortName = "选择排序";
break;
case "quickSort":
sortName = "快速排序";
break;
default:
break;
}
long start = System.currentTimeMillis();
//此处一定要使用proxy的invokeSuper方法来调用目标类的方法
proxy.invokeSuper(object, args);
long end = System.currentTimeMillis();
System.out.println("本次" + sortName + "的执行时间为: " + (end -start) + "ms");
return null;
}
});
//生成代理类并返回一个实例
ArraySort2 arraySort = (ArraySort2) enhancer.create();
arraySort.bubbleSort(arr);
arraySort.selectSort(arr);
arraySort.quickSort(arr);
}
// 运行结果:
// 本次冒泡排序的执行时间为:12502ms
// 本次选择排序的执行时间为:829ms
// 本次快速排序的执行时间为:7ms
}
其他代理
-
远程代理
- 为一个位于不同地址空间的远程对象提供一个局域代表对象,这个不同的地址空间可以位于同一台机器中,也可以位于不同的机器中
- 应用场景
- Java使用RMI实现远程代理、web service
-
虚拟代理
- 根据需要创建开销很大的对象。通过代理对象来存放实例化需要很长时间的真实对象
- 优点
- 性能优化,减少响应时间
- 节省内存,推迟对象的实例化时间
- 加速应用程序的启动
- 缺点
- 不能保证特定的应用程序被创建,每次访问这个对象的时候都需要判断是否为null,增加了检测时间
- 流程
- 代理对象和真实对象实现相同的接口
- 代理对象把真实对象的引用作为它的实例变量的维护
- 当客户需要真实对象的时候,代理对象首先会检测真实对象是否已经被创建
- 如果没有,由代理对象创建真实对象,并把这个对象分配给引用变量,代理对象把调用转发给真实对象
- 应用场景
- 打开一个很大的HTML网页,可以很快的打开,但是图片却是随着用户的滑动一张一张的加载,这时虚拟代理代替了真实的图片,存储了真实图片的路径和尺寸。
-
安全代理
- 控制对一个对象的访问权限。
总结
意图:为其他对象提供一种代理以控制对这个对象的访问。
主要解决:在直接访问对象时带来的问题,比如说:要访问的对象在远程的机器上。在面向对象系统中,有些对象由于某些原因(比如对象创建开销很大,或者某些操作需要安全控制,或者需要进程外的访问),直接访问会给使用者或者系统结构带来很多麻烦,我们可以在访问此对象时加上一个对此对象的访问层。
何时使用:想在访问一个类时做一些控制。
如何解决:增加中间层。
关键代码:实现与被代理类组合。
应用实例:
- Windows 里面的快捷方式。
- 猪八戒去找高翠兰结果是孙悟空变的,可以这样理解:把高翠兰的外貌抽象出来,高翠兰本人和孙悟空都实现了这个接口,猪八戒访问高翠兰的时候看不出来这个是孙悟空,所以说孙悟空是高翠兰代理类。
- 买火车票不一定在火车站买,也可以去代售点。
- 一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金,并提供对签发人账号上资金的控制。
- spring aop。
优点:
- 职责清晰。
- 高扩展性。
- 智能化。
缺点:
- 由于在客户端和真实主题之间增加了代理对象,因此有些类型的代理模式可能会造成请求的处理速度变慢。
- 实现代理模式需要额外的工作,有些代理模式的实现非常复杂。
使用场景:
按职责来划分,通常有以下使用场景:
- 远程代理。
- 虚拟代理。
- Copy-on-Write 代理。
- 保护(Protect or Access)代理。
- Cache代理。
- 防火墙(Firewall)代理。
- 同步化(Synchronization)代理。
- 智能引用(Smart Reference)代理。
注意事项:
- 和适配器模式的区别:适配器模式主要改变所考虑对象的接口,而代理模式不能改变所代理类的接口。
- 和装饰器模式的区别:装饰器模式为了增强功能,而代理模式是为了加以控制。