结构型模式中
1、装饰模式
软件开发过程中,有时候想用一些现存的组件,这些组件可能只是完成了一些核心功能,但在不改变其结构的情况下,可以动态的扩展其功能,所有这些都可以用装饰模式来实现。
1.1. 装饰模式的定义与特点
装饰模式(Decorator)指的是在不改变现有类的结构的情况下,动态给该对象增加一些职责,说白了就是额外增加一些功能,它属于对象结构型构造。
装饰(Decorator)模式的主要优点有:采用装饰模式扩展对象的功能比采用继承方式更加灵活。可以设计出多个不同的具体装饰类,创造出多个不同行为的组合。但是缺点是增加了许多子类,如果过度使用会使程序变得很复杂。
1.2.装饰模式的结构与实现
通常情况下,扩展一个类的功能会使用继承的方式来实现,但是继承具有静态特征,耦合度高,并且随着扩展功能的增加,子类会膨胀。如果使用组合关系来创建一个包含对象来包裹真实对象,并在保持真实对象的类结构不变的前提下,为其提供额外的功能,这就是装饰模式的目标。
装饰模式主要包含以下:
抽象构件角色(Component):定义一个抽象接口以规范准备接受附加责任的对象。
具体构件角色(Concrete Component):实现抽象构件,通过装饰角色为其添加一些职责。
抽象装饰(Decorator)角色:继承抽象构件,并包含具体构件的实例,可以通过其之类扩展具体构件的功能。
具体装饰(Concrete Decorator)角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任。
装饰模式的实现代码如下:
//抽象构件角色 interface Component { public void operation(); } //具体构件角色 class ConcreteCompoent implements Component { public ConcreteCompoent(){ System.out.println("创建具体构件角色"); } @Override public void operation() { System.out.println("调用具体构件角色的方法operation()"); } } //抽象装饰角色 class Decorator implements Component{ private Component component; public Decorator(Component component){ this.component = component; } @Override public void operation() { component.operation(); } } //具体装饰角色 class ConcreteDecorator extends Decorator { public ConcreteDecorator(Component component){ super(component); } public void operation(){ super.operation(); addedFunction(); } public void addedFunction(){ System.out.println("为具体构件角色增加额外的功能addedFuction"); } } public class TestDecoratorPattern { public static void main(String[] args) { Component component = new ConcreteCompoent();//生成具体构件对象 component.operation(); System.out.println("-------------------------------------------"); Component component1 = new ConcreteDecorator(component);//生成具体装饰角色的对象 component1.operation(); } }
1.3.装饰模式的应用场景
装饰模式通常在以下几种情况下使用:
(1)当需要给现有类添加附加职责,而又不能采用生成子类的方法进行扩充的时候
(2)当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时,采用继承关系很难实现,而采用装饰模式却很好实现
(3)当对象的功能要求可以动态地添加,也可以再动态地撤销时。
装饰模式在Java中语言中的最著名的应用莫过于Java I/O标准库的设计。
例如:InputStream的子类FilterInputStream,OutputStream的子类FilterOutputStream,Reader的子类BufferedReader以及FilterReader,还有Writer的子类BufferedWriter、FilterWriter以及PrinterWriter等,他们都是抽象装饰类。
下面是FileReader增加缓存区而采用的装饰类BufferedReader的例子:
BufferedReader in = new BufferedReader(new FileReader(“filename.txt”)); string s = in.ReadLine();
1.4.模式的扩展
装饰模式所包含的四个角色不是任何时候都要存在的,在有些应用环境下模式是可以简化的,如以下两种情况:
(1).如果只有一个具体构件而没有抽象构件时候,可以让抽象装饰继承具体构件,结构图如下:
(2).如果只有一个具体装饰时,可以将抽象装饰和具体装饰合并结构图如下:
2 外观模式Facade
现实生活中,常常存在办事复杂的例子,比如学生时代令人讨厌的科研经费报销,比如离职跑公司部门盖章。这个时候如果有一个综合部门能解决一切手续问题就好了。软件设计中,当一个系统中的功能越来越强,子系统越来越多,客户对系统的访问也会越来越复杂。这时候如果系统内部发生变化,客户端也跟着变化,这就违背了“开闭原则”,这个时候有必要为多了子系统提供一个统一的接口,从而降低系统的耦合度,这就是外观模式的目标。
1.1. 外观的定义与特点
外观(Facade)模式是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口,外部应用程序不用关心内部子系统的具体的细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性。
外观(Facade)模式是“迪米特法则”的典型应用,它有以下主要优点。
- 降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类。
- 对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易。
- 降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程,因为编译一个子系统不会影响其他的子系统,也不会影响外观对象。
外观(Facade)模式的主要缺点如下:
- 不能很好地限制客户使用子系统类。
- 增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。
1.2. 外观模式的结构与实现
外观模式的结构比较简单,主要是定义了一个高层接口。它包含了对各个子系统的引用,客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。
模式包含以下角色:
(1)外观角色(Facade):为多个子系统对外提供一个共同的接口。
(2)子系统角色(Sub system):实现系统的部分功能,客户可以通过外观角色访问它。
(3)客户角色(client):通过一个外观访问各个子系统的功能。
其结构图如下所示:
思考:其实甚至可以将子系统角色分别去实现一个共同的接口,这样在外观模式维护一个接口的list的成员变量,通过add子系统来添加新的子系统对象。
装饰模式的实现代码如下:
// 外观角色 class Facade{ private SubSystem01 subsystem01 = new SubSystem01(); private SubSystem02 subsystem02 = new SubSystem02(); private SubSystem03 subsystem03 = new SubSystem03(); public void method(){ subsystem01.method1(); subsystem02.method2(); subsystem03.method3(); } } //子系统1 class SubSystem01{ public void method1(){ System.out.println("子系统01的method1被调用!"); } } //子系统2 class SubSystem02{ public void method2(){ System.out.println("子系统02的method2呗调用!"); } } //子系统3 class SubSystem03{ public void method3(){ System.out.println("子系统03的method3被调用!"); } } public class TestFacadePattern { public static void main(String[] args) { Facade fac = new Facade(); fac.method(); } }
1.3 外观模式的应用场景
(1)对分层结构构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
(2)当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问
(3)当客户端与多个子系统之间存在很大的联系时候,引用外观模式可以将它们进行分离。从而提高子系统的独立性和可移植性。
1.4 外观模式的扩展
在外观模式中,当增加或者移除子系统是需要修改外观类,这就违背了“开闭原则”,如果引入抽象外观类,则一定程度上解决该问题。

· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构
· 字符编码:从基础到乱码解决
· 提示词工程——AI应用必不可少的技术