一、装饰器模式
1、概述
1、定义:
装饰器(Decorator)模式指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式
,它属于对象结构型模式。比继承更有弹性,体现了开闭原则。
2、主要角色
1、抽象构件(Component):是一个接口或者抽象类,是定义我们最核心的对象,也可以说是最原始的对象,比如饮料。
2、具体构件(ConcreteComponent):实现抽象构件,可以单独用,也可通过装饰角色将其进行装饰,比如咖啡。
3、抽象装饰(Decorator):一般是一个抽象类,继承或实现Component,在它的属性里面有一个变量指向Component抽象构件
。
4、具体装饰(ConcreteDecorator):实现抽象装饰的相关方法,并给具体构件对象添加新的责任,比如把一个普通咖啡装饰成巧克力牛奶咖啡。
3、装饰器模式实现
@Data
public abstract class Drink {
private String des;
private float price = 0.0f;
public abstract float cost();
}
public class Coffee extends Drink {
@Override
public float cost() {
return super.getPrice();
}
}
public class DeCoffee extends Coffee {
public DeCoffee() {
setDes("无因咖啡");
setPrice(10.0f);
}
}
public class LongBlack extends Coffee {
public LongBlack() {
setDes("美式");
setPrice(12.0f);
}
}
public class Decorator extends Drink {
private Drink drink;
public Decorator(Drink drink) {
this.drink = drink;
}
@Override
public float cost() {
return super.getPrice() + drink.cost();
}
@Override
public String getDes() {
return super.getDes() + " " + getPrice() + " && " + drink.getDes();
}
}
public class Milk extends Decorator {
public Milk(Drink drink) {
super(drink);
setDes("牛奶");
setPrice(3.0f);
}
}
public class Chocolate extends Decorator {
public Chocolate(Drink drink) {
super(drink);
setDes("巧克力");
setPrice(2.0f);
}
}
public class Test {
public static void main(String[] args) {
Drink order = new LongBlack();
System.out.println("费用 = " + order.cost());
System.out.println("描述 = " + order.getDes());
order = new Milk(order);
System.out.println("order 加入一份牛奶 费用 = " + order.cost());
System.out.println("order 加入一份牛奶 描述 = " + order.getDes());
order = new Chocolate(order);
System.out.println("order 加入一份牛奶 加入一份巧克力 费用 = " + order.cost());
System.out.println("order 加入一份牛奶 加入一份巧克力 描述 = " + order.getDes());
order = new Chocolate(order);
System.out.println("order 加入一份牛奶 加入2份巧克力 费用 = " + order.cost());
System.out.println("order 加入一份牛奶 加入2份巧克力 描述 = " + order.getDes());
System.out.println("===========================");
Drink order2 = new DeCoffee();
System.out.println("order2 无因咖啡 费用 = " + order2.cost());
System.out.println("order2 无因咖啡 描述 = " + order2.getDes());
order2 = new Milk(order2);
System.out.println("order2 无因咖啡 加入一份牛奶 费用 = " + order2.cost());
System.out.println("order2 无因咖啡 加入一份牛奶 描述 = " + order2.getDes());
}
}
4、优缺点说明
1、优点:
-
装饰器是继承的有力补充,比继承灵活,在不改变原有对象的情况下,动态的给一个对象扩展功能,即插即用。
-
通过使用不用装饰类及这些装饰类的排列组合,可以实现不同效果。
-
装饰器模式完全遵守开闭原则。
2、缺点:
-
装饰器模式会增加许多子类,过度使用会增加程序得复杂性。
5、应用场景
1、当需要给一个现有类添加附加职责,而又不能采用生成子类的方法进行扩充时。例如,该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
2、当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时,采用继承关系很难实现,而采用装饰器模式却很好实现。
3、当对象的功能要求可以动态地添加,也可以再动态地撤销时。
二、组合模式
1、概述
1、组合(Composite Pattern)模式的定义:
有时又叫作整体-部分(Part-Whole)模式,它是一种将对象组合成树状的层次结构的模式,用来表示“整体-部分”的关系,使用户对单个对象和组合对象具有一致的访问性,即:组合能让客户以一致的方式处理个别对象以及组合对象。
2、组合模式一般用来描述整体与部分的关系,它将对象组织到树形结构中,顶层的节点被称为根节点,根节点下面可以包含树枝节点和叶子节点,树枝节点下面又可以包含树枝节点和叶子节点,树形结构图如下。

3、由上图可以看出:
其实根节点和树枝节点本质上属于同一种数据类型,可以作为容器使用;而叶子节点与树枝节点在语义上不属于用一种类型。但是在组合模式中,会把树枝节点和叶子节点看作属于同一种数据类型(用统一接口定义),让它们具备一致行为。这样,在组合模式中,整个树形结构中的对象都属于同一种类型,带来的好处就是用户不需要辨别是树枝节点还是叶子节点,可以直接进行操作,给用户的使用带来极大的便利。
2、主要角色
1、抽象构件(Component):它的主要作用是为树叶构件和树枝构件声明公共接口,并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口;在安全式的组合模式中不声明访问和管理子类的接口,管理工作由树枝构件完成。(总的抽象类或接口,定义一些通用的方法,比如新增、删除)。
2、树叶构件(Leaf):是组合中的叶节点对象,它没有子节点,用于继承或实现抽象构件。
3、树枝构件(Composite) /中间构件:是组合中的分支节点对象,它有子节点,用于继承和实现抽象构件。它的主要作用是存储和管理子部件,通常包含 Add()、Remove()、GetChild() 等方法。
3、组合模式实现
例:一个学校的院系结构,一个学校有多个学院,一个学院有多个院系。
@Data
@AllArgsConstructor
public abstract class OrganizationComponent {
private String name;
private String desc;
protected void add(OrganizationComponent organizationComponent) {
throw new UnsupportedOperationException();
}
protected void remove(OrganizationComponent organizationComponent) {
throw new UnsupportedOperationException();
}
protected abstract void print();
}
public class Department extends OrganizationComponent {
public Department(String name, String desc) {
super(name, desc);
}
@Override
protected void print() {
System.out.println(getName());
}
}
public class College extends OrganizationComponent {
List<OrganizationComponent> organizationComponents = new ArrayList<>();
public College(String name, String desc) {
super(name, desc);
}
@Override
protected void add(OrganizationComponent organizationComponent) {
organizationComponents.add(organizationComponent);
}
@Override
protected void remove(OrganizationComponent organizationComponent) {
organizationComponents.remove(organizationComponent);
}
@Override
protected void print() {
System.out.println("===========" + getName() + "===========");
organizationComponents.stream().forEach(organizationComponent -> {
organizationComponent.print();
});
}
}
public class University extends OrganizationComponent {
List<OrganizationComponent> organizationComponents = new ArrayList<>();
public University(String name, String desc) {
super(name, desc);
}
@Override
protected void add(OrganizationComponent organizationComponent) {
organizationComponents.add(organizationComponent);
}
@Override
protected void remove(OrganizationComponent organizationComponent) {
organizationComponents.remove(organizationComponent);
}
@Override
protected void print() {
System.out.println("===========" + getName() + "===========");
organizationComponents.stream().forEach(organizationComponent -> {
organizationComponent.print();
});
}
}
public class Test {
public static void main(String[] args) {
OrganizationComponent university = new University("华中科技大学","武汉一流大学");
OrganizationComponent computerCollege = new College("计算机学院", "计算机学院");
OrganizationComponent infoEngineerCollege = new College("信息工程学院", "信息工程学院");
university.add(computerCollege);
university.add(infoEngineerCollege);
computerCollege.add(new Department("软件工程","软件真不错"));
computerCollege.add(new Department("网络工程","网络工程"));
computerCollege.add(new Department("计算机科学与技术","计算机科学与技术"));
infoEngineerCollege.add(new Department("通信工程","通信工程"));
infoEngineerCollege.add(new Department("信息工程","信息工程"));
university.print();
}
}
4、优缺点说明
1、优点:
-
组合模式使得客户端代码可以一致地处理单个对象和组合对象,无须关心自己处理的是单个对象,还是组合对象,这简化了客户端代码;
-
更容易在组合体内加入新的对象,客户端不会因为加入了新的对象而更改源代码,满足“开闭原则”;
2、缺点:
-
设计较复杂,客户端需要花更多时间理清类之间的层次关系。
5、应用场景
1、在需要表示一个对象整体与部分的层次结构的场合。
2、要求对用户隐藏组合对象与单个对象的不同,用户可以用统一的接口使用组合结构中的所有对象的场合。
三、外观模式
1、概述
1、外观(Facade)模式的定义:
又叫做门面模式,是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式,模式对外有一个统一接口,外部应用程序不用关心内部子系统的具体细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性。
2、主要角色
1、外观角色(Facade):为多个子系统对外提供一个共同的接口。
2、子系统角色(Sub System):实现系统的部分功能,客户可以通过外观角色访问它。
3、客户角色(Client):通过一个外观角色访问各个子系统的功能。
3、外观模式实现
public class Facade {
private SubSystem01 obj1 = new SubSystem01();
private SubSystem02 obj2 = new SubSystem02();
private SubSystem03 obj3 = new SubSystem03();
public void method() {
obj1.method1();
obj2.method2();
obj3.method3();
}
}
public class SubSystem01 {
public void method1() {
System.out.println("子系统01的method1()被调用!");
}
}
public class SubSystem02 {
public void method2() {
System.out.println("子系统02的method2()被调用!");
}
}
public class SubSystem03 {
public void method3() {
System.out.println("子系统03的method3()被调用!");
}
}
public class Client {
public static void main(String[] args) {
Facade f = new Facade();
f.method();
}
}
4、优缺点说明
1、优点:
-
降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类。
-
对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易。
-
降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程,因为编译一个子系统不会影响其他的子系统,也不会影响外观对象。
2、缺点:
-
不能很好地限制客户使用子系统类,很容易带来未知风险。
-
增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。
5、应用场景
1、对分层结构系统构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
2、当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问。
3、当客户端与多个子系统之间存在很大的联系时,引入外观模式可将它们分离,从而提高子系统的独立性和可移植性。
四、享元模式
1、概述
1、享元(Flyweight)模式的定义:
运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销,从而提高系统资源的利用率。在享元模式这样理解,“享”就表示共享,“元”表示对象。(比如:数据库连接池,里面都是创建好的连接对象,需要使用的时候直接拿来用,避免重复创建。)
2、享元模式的定义提出了两个要求,细粒度和共享对象。因为要求细粒度,所以不可避免地会使对象数量多且性质相近,此时我们就将这些对象的信息分为两个部分:内部状态和外部状态。
-
内部状态指对象共享出来的信息,存储在享元信息内部,并且不会随环境的改变而改变。
-
外部状态指对象得以依赖的一个标记,随环境的改变而改变,不可共享。
3、比如,连接池中的连接对象,保存在连接对象中的用户名、密码、连接URL等信息,在创建对象的时候就设置好了,不会随环境的改变而改变,这些为内部状态。而当每个连接要被回收利用时,我们需要将它标记为可用状态,这些为外部状态。
4、享元模式的本质:缓存共享对象,降低内存消耗
。
2、主要角色
1、抽象享元角色(Flyweight):是所有的具体享元类的基类,为具体享元规范需要实现的公共接口,非享元的外部状态以参数的形式通过方法传入。
2、具体享元(Concrete Flyweight)角色:实现抽象享元角色中所规定的接口。
3、非享元(Unsharable Flyweight)角色:是不可以共享的外部状态,它以参数的形式注入具体享元的相关方法中。
4、享元工厂(Flyweight Factory)角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检査系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。
3、享元模式的实现
@Data
@AllArgsConstructor
public class UnsharedConcreteFlyweight {
private String info;
}
public interface Flyweight {
void operation(UnsharedConcreteFlyweight state);
}
public class ConcreteFlyweight implements Flyweight {
private String key;
ConcreteFlyweight(String key) {
this.key = key;
System.out.println("具体享元" + key + "被创建!");
}
@Override
public void operation(UnsharedConcreteFlyweight state) {
System.out.print("具体享元" + key + "被调用,");
System.out.println("非享元信息是:" + state.getInfo());
}
}
public class FlyweightFactory {
private HashMap<String, Flyweight> flyweights = new HashMap<String, Flyweight>();
public Flyweight getFlyweight(String key) {
Flyweight flyweight = (Flyweight) flyweights.get(key);
if (flyweight != null) {
System.out.println("具体享元" + key + "已经存在,被成功获取!");
} else {
flyweight = new ConcreteFlyweight(key);
flyweights.put(key, flyweight);
}
return flyweight;
}
}
public class Client {
public static void main(String[] args) {
FlyweightFactory factory = new FlyweightFactory();
Flyweight f01 = factory.getFlyweight("a");
Flyweight f02 = factory.getFlyweight("a");
Flyweight f03 = factory.getFlyweight("a");
Flyweight f11 = factory.getFlyweight("b");
Flyweight f12 = factory.getFlyweight("b");
f01.operation(new UnsharedConcreteFlyweight("第1次调用a。"));
f02.operation(new UnsharedConcreteFlyweight("第2次调用a。"));
f03.operation(new UnsharedConcreteFlyweight("第3次调用a。"));
f11.operation(new UnsharedConcreteFlyweight("第1次调用b。"));
f12.operation(new UnsharedConcreteFlyweight("第2次调用b。"));
}
}
4、优缺点说明
1、优点:
-
相同对象只要保存一份,这降低了系统中对象的数量,从而降低了系统中细粒度对象给内存带来的压力。
2、缺点:
-
为了使对象可以共享,需要将一些不能共享的状态外部化,这将增加程序的复杂性。
-
读取享元模式的外部状态会使得运行时间稍微变长。
5、应用场景
1、当系统中多处需要同一组信息时,可以把这些信息封装到一个对象中,然后对该对象进行缓存,这样,一个对象就可以提供给多出需要使用的地方,避免大量同一对象的多次创建,降低大量内存空间的消耗。
2、享元模式其实是工厂方法模式
的一个改进机制,享元模式同样要求创建一个或一组对象,并且就是通过工厂方法模式生成对象的,只不过享元模式为工厂方法模式增加了缓存这一功能。
-
系统中存在大量相同或相似的对象,这些对象耗费大量的内存资源。
-
大部分的对象可以按照内部状态进行分组,且可将不同部分外部化,这样每一个组只需保存一个内部状态。
-
由于享元模式需要额外维护一个保存享元的数据结构
,所以应当在有足够多的享元实例时才值得使用享元模式。