杨凌网站建设推广,手机网站开发下载,做个淘宝客网站怎么做,短视频营销策划方案对常用设计模式的总结#xff0c;也是对设计模式专栏的总结
简单工厂模式
简单工厂模式#xff08;Simple Factory Pattern#xff09;是一种创建型设计模式#xff0c;它提供了一种创建对象的最佳方式#xff0c;通过将对象的创建逻辑封装在一个工厂类中#xff0c;客…对常用设计模式的总结也是对设计模式专栏的总结
简单工厂模式
简单工厂模式Simple Factory Pattern是一种创建型设计模式它提供了一种创建对象的最佳方式通过将对象的创建逻辑封装在一个工厂类中客户端不需要知道具体的创建细节只需要向工厂类请求所需对象即可。
简单工厂模式组成
在简单工厂模式中主要涉及三个角色抽象产品、具体产品和简单工厂。
抽象产品Abstract Product
抽象产品是具体产品类的共同接口它定义了产品的通用方法。抽象产品可以是一个接口或抽象类具体的实现由具体产品类来完成。
具体产品Concrete Product
具体产品是抽象产品的实现类它实现了抽象产品中定义的方法。在简单工厂模式中每个具体产品都对应一个具体的产品类。
简单工厂Simple Factory
简单工厂是一个包含创建产品对象的静态方法的类。它根据客户端的请求创建相应的具体产品对象并返回给客户端使用。简单工厂隐藏了对象的创建细节客户端只需通过工厂类获取所需对象而无需直接实例化具体产品类。
三者关系
1、抽象产品通过定义产品的通用接口规范了具体产品的行为。 2、具体产品是抽象产品的实现类负责实现抽象产品中定义的方法。 3、简单工厂作为一个工厂类封装了对象的创建过程。它根据客户端的请求创建相应的具体产品对象并返回给客户端使用。
核心思想
将对象的创建过程封装在一个工厂类中客户端只需通过工厂类的静态方法来获取所需对象而无需直接实例化具体产品类。这样可以降低客户端与具体产品类之间的耦合度并且方便了产品类型的扩展和维护。
Java代码实现
首先我们定义一个抽象产品接口 Product其中包含一个抽象方法 use()
public interface Product {void use();
}然后我们创建两个具体产品类 ProductA 和 ProductB它们实现了抽象产品接口 Product
public class ProductA implements Product {Overridepublic void use() {System.out.println(Product A is being used.);}
}public class ProductB implements Product {Overridepublic void use() {System.out.println(Product B is being used.);}
}接下来我们创建一个简单工厂类 SimpleFactory它包含一个静态方法 createProduct(String type)根据传入的参数类型创建相应的产品对象
public class SimpleFactory {public static Product createProduct(String type) {if (type.equals(A)) {return new ProductA();} else if (type.equals(B)) {return new ProductB();}return null;}
}最后我们可以在客户端代码中使用简单工厂模式来创建具体产品对象
//客户端
public class Client {public static void main(String[] args) {Product productA SimpleFactory.createProduct(A);productA.use(); // Output: Product A is being used.Product productB SimpleFactory.createProduct(B);productB.use(); // Output: Product B is being used.}
}代码分析
客户端通过调用 SimpleFactory.createProduct() 方法来创建具体产品对象而无需直接实例化具体产品类。这样客户端与具体产品之间的耦合度降低了同时也方便了产品类型的扩展和维护。
简单工厂类 SimpleFactory 包含一个静态方法 createProduct(String type)该方法根据传入的参数类型创建相应的产品对象。在实际应用中根据具体需求可以使用更复杂的逻辑来创建对象例如读取配置文件或数据库来确定创建哪个具体产品。
在客户端代码中我们通过调用 SimpleFactory.createProduct() 方法来创建具体产品对象。客户端只需知道产品的类型而无需关心具体的创建细节。这样可以降低客户端与具体产品类之间的耦合度并且方便了产品类型的扩展和维护。
优缺点分析
优点
封装了对象的创建过程
简单工厂模式将对象的创建过程封装在一个工厂类中客户端只需知道产品的类型而无需关心具体的创建细节。这样可以降低客户端的复杂性并且方便了产品类型的扩展和维护。
降低了客户端与具体产品类之间的耦合度
客户端只需通过工厂类获取所需对象而无需直接实例化具体产品类。这样可以降低客户端与具体产品类之间的依赖关系使客户端代码更加灵活和可维护。
方便了产品类型的扩展和维护
在简单工厂模式中如果需要新增产品类型只需修改工厂类的代码即可。这样可以方便地添加新的产品类型而无需修改客户端代码。同时也方便了产品类型的维护集中管理了对象的创建过程。
缺点
违反了开闭原则
在简单工厂模式中当新增产品类型时需要修改工厂类的代码。这违反了开闭原则对于已经存在的代码进行修改可能会引入新的风险。因此如果产品类型经常变化不适合使用简单工厂模式。
工厂类职责过重
在简单工厂模式中工厂类负责创建所有的产品对象。随着产品类型的增多工厂类的代码会变得越来越复杂职责过重。这违反了单一职责原则不利于代码的维护和扩展。
总结
简单工厂模式是一种简单且常用的创建型设计模式适用于创建对象较少且相对简单的场景。它封装了对象的创建过程降低了客户端的复杂性并且方便了产品类型的扩展和维护。然而简单工厂模式违反了开闭原则对于产品类型经常变化的情况不适用。此外工厂类的职责过重也是其缺点之一。因此在实际应用中需要根据具体情况选择合适的创建型模式。 策略模式
策略模式Strategy Pattern是一种行为型设计模式它定义了一系列的算法将每个算法封装起来使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户端。
主要角色
当我们使用策略模式时通常会涉及三个主要角色环境Context、抽象策略Strategy和具体策略Concrete Strategy。
环境Context
环境类是策略模式的核心它持有一个策略对象的引用并在运行时根据具体需求调用策略对象的算法。环境类提供了一个接口或方法用于设置和获取策略对象。在客户端使用策略模式时通常需要与环境类进行交互。
抽象策略Strategy
抽象策略类是策略模式的接口或抽象类定义了具体策略类所必须实现的算法。抽象策略类通常包含一个或多个抽象方法用于描述策略的行为。客户端通过调用抽象策略类中的方法来使用具体策略。
具体策略Concrete Strategy
具体策略类是策略模式的实现类实现了抽象策略类中定义的算法。具体策略类根据具体的业务需求实现了不同的算法逻辑。在客户端使用策略模式时可以根据需要选择合适的具体策略类。
角色总结
环境类持有一个策略对象的引用并在运行时根据具体需求调用策略对象的算法。抽象策略类定义了具体策略类所必须实现的算法而具体策略类实现了具体的算法逻辑。通过使用策略模式可以将算法的定义和使用分离提高代码的灵活性、可维护性和可扩展性。
核心思想
策略模式的核心思想是将算法的定义和使用分离。在策略模式中我们将不同的算法封装成不同的策略类并通过环境类持有一个策略对象的引用。在运行时根据具体需求选择合适的策略对象并调用其算法。
封装算法
策略模式将不同的算法封装成不同的策略类。每个策略类都实现了一种具体的算法逻辑。通过封装算法我们可以将其与其他代码分离使得算法的定义更加清晰、可读、可维护。 定义抽象策略
策略模式定义了一个抽象策略类其中包含了策略类所必须实现的方法。抽象策略类可以是一个接口或者抽象类。通过定义抽象策略我们可以统一不同策略类的接口使得客户端可以以统一的方式使用不同的策略。
使用环境类
策略模式通过环境类持有一个策略对象的引用。在运行时客户端可以根据具体需求选择合适的策略对象并将其设置到环境类中。环境类在运行时根据具体需求调用策略对象的算法实现了算法的动态切换。
思想总结
通过将算法的定义和使用分离策略模式提高了代码的灵活性、可维护性和可扩展性。它使得算法的修改和增加变得更加简单不需要修改原有的代码。同时策略模式也符合开闭原则可以方便地增加新的策略类。
Java代码实现——以一个游戏角色攻击方式的例子
首先我们定义一个抽象策略类 AttackStrategy它声明了一个 attack() 方法
public interface AttackStrategy {void attack();
}然后我们定义两种具体的攻击策略类MeleeAttackStrategy 和 RangedAttackStrategy它们分别实现了 AttackStrategy 接口
public class MeleeAttackStrategy implements AttackStrategy {Overridepublic void attack() {System.out.println(近战攻击);}
}public class RangedAttackStrategy implements AttackStrategy {Overridepublic void attack() {System.out.println(远程攻击);}
}接下来我们定义一个环境类 Character它持有一个 AttackStrategy 对象并提供一个 setAttackStrategy() 方法用于动态设置攻击策略
public class Character {private AttackStrategy attackStrategy;public void setAttackStrategy(AttackStrategy attackStrategy) {this.attackStrategy attackStrategy;}public void attack() {attackStrategy.attack();}
}最后我们可以在客户端中使用策略模式 public class Client {public static void main(String[] args) {Character character new Character();character.setAttackStrategy(new MeleeAttackStrategy());character.attack(); // 输出近战攻击character.setAttackStrategy(new RangedAttackStrategy());character.attack(); // 输出远程攻击}
}代码分析
在上述代码中我们通过设置不同的攻击策略使得角色可以使用不同的攻击方式。这样当需要增加新的攻击方式时只需要实现新的具体策略类并在客户端中设置新的攻击策略即可而不需要修改原有的代码。
优缺点分析
优点
算法的封装性
策略模式将不同的算法封装成不同的策略类使得每个策略类都只关注自己的算法逻辑提高了代码的可读性和可维护性。
策略的替换性
由于策略模式将算法的定义和使用分离所以在运行时可以根据具体需求选择不同的策略对象实现算法的动态切换。这样可以方便地替换和扩展算法而不需要修改原有的代码。
算法的扩展性
策略模式符合开闭原则可以方便地增加新的策略类。当需要增加新的算法时只需要添加一个新的策略类并在环境类中设置该策略对象即可不需要修改原有的代码。
算法的复用性
策略模式将算法封装成独立的策略类可以在不同的场景中复用相同的算法。这样可以避免代码的重复编写提高了代码的复用性。 缺点
增加了类的数量
使用策略模式会增加类的数量每个具体策略类都需要单独定义一个类。如果策略较多可能会导致类的数量过多增加代码的复杂性。
客户端需要了解不同的策略类
客户端在使用策略模式时需要了解不同的策略类并选择合适的策略对象。如果策略较多可能会增加客户端的复杂性。
策略的选择逻辑
在使用策略模式时需要根据具体需求选择合适的策略对象。这个选择逻辑可能会比较复杂需要考虑多个因素增加了代码的复杂性。
优缺点总结
总的来说策略模式通过将算法的定义和使用分离提高了代码的灵活性、可维护性和可扩展性。它将不同的算法封装成不同的策略类实现了算法的动态切换和复用。然而策略模式也会增加类的数量增加客户端的复杂性并且需要考虑策略的选择逻辑。在使用策略模式时需要权衡其优点和缺点选择合适的使用方式。
单一职责原则
单一职责原则Single Responsibility PrincipleSRP是设计模式中的一项原则它指出一个类或模块应该有且只有一个引起它变化的原因。换句话说一个类或模块应该只负责一项职责。
核心思想
职责的划分
将系统中的功能和行为划分为不同的职责每个类或模块只负责一种相关的职责。这样可以使得类的职责更加明确和清晰便于理解和维护。
单一变化原则
一个类或模块应该只有一个引起它变化的原因。如果一个类负责多种不相关的职责那么对其中一个职责的修改可能会影响到其他职责增加了代码的风险和复杂性。
高内聚性
类的内聚性指的是类内部的成员之间联系的紧密程度。遵守单一职责原则可以提高类的内聚性使得类内部的成员相互关联度高功能相关的代码放在同一个类中便于理解和维护。
低耦合性
类之间的耦合性指的是彼此之间的依赖程度。遵守单一职责原则可以降低类之间的耦合性使得类之间的依赖关系更加清晰和简单减少代码的依赖和影响范围。
核心总结
单一职责原则的核心思想是将一个类或模块的职责限定在一个很小的范围内使其只负责一种相关的功能或行为。这样可以保持类的高内聚性、低耦合性提高代码的可读性、可维护性和可扩展性。
举例
假设我们有一个图书管理系统其中包含了图书的借阅和归还功能。我们可以将这个系统划分为以下几个类
图书类Book
负责表示图书的属性和行为比如书名、作者、借阅状态等。
用户类User
负责表示用户的属性和行为比如用户名、密码、借阅图书等。
图书管理类Library
负责管理图书的借阅和归还功能。
分析
在这个例子中每个类都只负责一种相关的职责符合了单一职责原则。图书类只负责表示图书的属性和行为用户类只负责表示用户的属性和行为图书管理类只负责管理图书的借阅和归还功能。
不遵守单一职责原则可能引发的问题
类的职责不清晰
一个类负责了多种不相关的职责使得代码难以理解和维护。
类的修改影响范围过大
当一个类负责多种职责时对其中一个职责的修改可能会影响到其他职责增加了代码的风险和复杂性。
难以重用和扩展
一个类负责多种职责时可能会导致代码的耦合性增加使得难以重用和扩展。
Java代码实现
// 图书类
class Book {private String title;private String author;private int pageCount;// 构造函数、getter和setter方法省略// 图书的展示功能public void display() {System.out.println(Title: this.title);System.out.println(Author: this.author);System.out.println(Page Count: this.pageCount);}
}// 图书管理类
class Library {private ListBook books;// 构造函数、getter和setter方法省略// 图书的借阅功能public void borrowBook(Book book) {if (books.contains(book)) {books.remove(book);System.out.println(Borrowed book: book.getTitle());} else {System.out.println(Book not available for borrowing.);}}// 图书的归还功能public void returnBook(Book book) {books.add(book);System.out.println(Returned book: book.getTitle());}
}程序分析
我们定义了两个类Book和Library。Book类负责表示图书的属性和行为包括展示图书的功能Library类负责管理图书的借阅和归还功能。
通过将图书的展示功能和图书的借阅、归还功能分别放在不同的类中我们遵守了单一职责原则。每个类只负责一种相关的职责使得代码更加清晰和易于维护。
当我们需要使用这些功能时可以直接调用相应的方法
Book book new Book(Design Patterns, Gang of Four, 400);
book.display();Library library new Library();
library.borrowBook(book);
library.returnBook(book);这样我们可以很方便地使用图书的展示、借阅和归还功能而不会影响到其他相关的功能。
总结
总结来说单一职责原则是设计模式中的一项重要原则它要求将功能划分得更加细致使得每个类或模块 只负责一种相关的职责。遵守单一职责原则可以提高代码的可读性、可维护性和可扩展性。
开放封闭原则
开放封闭原则是面向对象设计中的一个重要原则它指导我们编写可扩展、可维护和可复用的代码。
核心思想
软件实体类、模块、函数等应该对扩展开放对修改封闭。也就是说当需要增加新的功能时应该通过扩展已有的代码来实现而不是修改已有的代码。
关键词概括
扩展
当需求发生变化时我们希望能够方便地增加新的功能或特性而不需要对已有的代码进行修改。这样可以减少引入新错误的风险。
封闭
已有的代码应该是稳定的不应该受到需求变化的影响。即使需求发生变化我们也不应该修改已有的代码。这样可以保护已有的代码防止引入新的错误。
解释
抽象和接口
通过定义抽象类或接口我们可以将可变的部分抽象出来定义一组公共的方法和属性。这样在需要扩展时我们只需要实现新的子类或实现新的接口即可而不需要修改已有的代码。
多态
通过使用多态我们可以在运行时动态地选择不同的实现。这样我们可以通过扩展已有的类或接口来实现新的功能而不需要修改已有的代码。
代码示例
// 定义一个接口
public interface Shape {void draw();
}// 定义一个实现类
public class Circle implements Shape {Overridepublic void draw() {System.out.println(Drawing a circle);}
}// 定义一个扩展类
public class Rectangle implements Shape {Overridepublic void draw() {System.out.println(Drawing a rectangle);}
}// 定义一个客户端类
public class Client {public void drawShapes(ListShape shapes) {for (Shape shape : shapes) {shape.draw();}}
}// 测试代码
public class Main {public static void main(String[] args) {Client client new Client();ListShape shapes new ArrayList();shapes.add(new Circle());shapes.add(new Rectangle());client.drawShapes(shapes);}
}代码解释
在上面的代码中我们定义了一个 Shape 接口它有一个 draw() 方法。然后我们定义了一个实现类 Circle 和一个扩展类 Rectangle它们都实现了 Shape 接口。
在客户端类 Client 中我们定义了一个 drawShapes() 方法它接受一个 List 参数并循环调用每个 Shape 对象的 draw() 方法。这样我们可以通过扩展 Shape 接口并实现新的子类来增加新的图形类型而不需要修改已有的代码。
在测试代码中我们创建了一个 Client 对象并传入一个包含 Circle 和 Rectangle 对象的 List。然后调用 drawShapes() 方法它会依次调用每个图形对象的 draw() 方法输出相应的图形。
这个示例代码演示了如何使用开放封闭原则来实现代码的扩展。通过定义一个公共的接口并实现多个子类我们可以在不修改已有的代码的情况下扩展代码的功能。
优缺点
优点
可扩展性
开放封闭原则可以使系统具有良好的扩展性。通过定义抽象类或接口并实现新的子类或接口我们可以在不修改已有的代码的情况下增加新的功能。
可维护性
开放封闭原则可以提高代码的可维护性。通过将可变的部分与稳定的部分分离开来我们可以更容易地理解和修改代码。当需求发生变化时我们只需要扩展已有的类或接口而不需要修改已有的代码。
可复用性
开放封闭原则可以增加代码的可复用性。通过定义抽象类或接口并实现新的子类或接口我们可以将相同的代码逻辑应用于不同的场景中。
高内聚低耦合
开放封闭原则可以提高代码的内聚性和减少代码的耦合性。通过将可变的部分封装在独立的类中并通过接口进行交互我们可以将代码分解为独立的模块从而提高代码的内聚性和减少代码的耦合性。
缺点
抽象设计的复杂性
开放封闭原则可能会增加代码的复杂性。通过引入抽象类或接口我们需要定义更多的类和接口这会增加代码的复杂性。
需要预留扩展点
开放封闭原则需要在设计时预留扩展点这可能会增加设计的难度。如果没有正确地预留扩展点可能需要修改已有的代码。
可能引入过度设计
开放封闭原则可能会导致过度设计。为了实现扩展性我们可能会引入过多的抽象类和接口这可能会增加代码的复杂性和理解难度。
总结
开放封闭原则是面向对象设计中的一个重要原则它的核心思想是对扩展开放对修改封闭。通过定义抽象类或接口并实现新的子类或接口可以在不修改已有的代码的情况下增加新的功能。这样可以提高系统的扩展性、可维护性和可复用性同时减少代码的耦合性和提高代码的内聚性。然而开放封闭原则也可能增加代码的复杂性和设计难度需要在实际应用中权衡利弊。总的来说开放封闭原则是一种有助于构建可扩展、可维护和可复用的系统的重要原则。
依赖倒转原则
依赖倒转原则Dependency Inversion PrincipleDIP是面向对象设计中的一个重要原则它指导着如何构建松耦合、可扩展和可维护的软件系统。该原则由罗伯特·C·马丁Robert C. Martin提出。
核心思想
通过抽象来解耦高层模块和低层模块之间的依赖关系。
关键点分析
a
高层模块不应该依赖于低层模块的具体实现而是依赖于抽象接口。这意味着高层模块应该定义一个抽象接口而低层模块实现该接口。通过依赖于抽象接口高层模块可以独立于具体实现进行编程。
b
抽象接口应该由高层模块定义而不是由低层模块定义。这样可以确保高层模块对于依赖的控制而不会受到低层模块的限制。高层模块可以根据自己的需求定义接口的方法和属性而不需要依赖于低层模块的具体实现细节。
c
依赖注入是实现依赖倒转原则的重要手段。通过依赖注入高层模块可以将具体实现类的对象传递给抽象接口。依赖注入可以通过构造函数、方法参数或者属性注入的方式实现。这样可以实现解耦高层模块不需要关心具体实现类的创建和管理。
优缺点分析
优点
降低模块间的耦合度
通过依赖倒转原则高层模块不依赖于低层模块的具体实现而是依赖于抽象接口。这样可以使得模块之间的耦合度降低提高代码的灵活性和可维护性。
提高代码的可扩展性
由于高层模块不依赖于低层模块的具体实现当需要新增或修改低层模块时只需要修改具体实现类而不需要修改高层模块的代码。这样可以提高代码的可扩展性减少对现有代码的影响。
便于进行单元测试
由于高层模块依赖于抽象接口可以通过使用模拟对象来进行单元测试而不需要依赖于具体实现类。这样可以更容易地进行测试提高代码的质量。 缺点
增加代码的复杂性
依赖倒转原则需要引入抽象接口和依赖注入等机制这会增加代码的复杂性和理解难度。特别是在项目规模较小或简单场景下引入这些机制可能会显得过于繁琐。
需要额外的设计和开发工作
在应用依赖倒转原则时需要进行额外的设计和开发工作包括定义抽象接口、实现具体实现类、进行依赖注入等。这会增加开发成本和工作量。
综上所述依赖倒转原则在一定程度上可以提高代码的灵活性、可维护性和可扩展性但也需要权衡其引入的复杂性和开发成本。在设计和开发过程中需要根据具体的场景和需求来决定是否采用依赖倒转原则。
Java代码实现
// 定义抽象接口
public interface MessageSender {void sendMessage(String message);
}// 具体实现类1
public class EmailSender implements MessageSender {Overridepublic void sendMessage(String message) {System.out.println(Sending email: message);}
}// 具体实现类2
public class SmsSender implements MessageSender {Overridepublic void sendMessage(String message) {System.out.println(Sending SMS: message);}
}// 高层模块依赖于抽象接口
public class NotificationService {private MessageSender messageSender;// 通过构造函数进行依赖注入public NotificationService(MessageSender messageSender) {this.messageSender messageSender;}public void sendNotification(String message) {// 调用抽象接口的方法messageSender.sendMessage(message);}
}// 测试代码
public class Main {public static void main(String[] args) {// 创建具体实现类的对象MessageSender emailSender new EmailSender();MessageSender smsSender new SmsSender();// 创建高层模块的对象并传入具体实现类的对象NotificationService emailNotificationService new NotificationService(emailSender);NotificationService smsNotificationService new NotificationService(smsSender);// 调用高层模块的方法emailNotificationService.sendNotification(Hello, this is an email notification.);smsNotificationService.sendNotification(Hello, this is an SMS notification.);}
}示例分析
在抽象接口MessageSender定义了发送消息的方法。具体实现类EmailSender和SmsSender分别实现了该接口并提供了发送邮件和发送短信的具体实现。高层模块NotificationService依赖于抽象接口MessageSender通过构造函数进行依赖注入从而实现了依赖倒转原则。
总结
依赖倒置原则强调了面向抽象编程的重要性通过抽象接口和依赖注入等技术可以降低模块之间的耦合度提高代码的灵活性和可维护性。
装饰模式
装饰模式Decorator Pattern是一种结构型设计模式它允许你动态地向一个对象添加额外的功能而不需要修改其原始类。通过将对象包装在装饰器类中你可以在不改变现有对象结构的情况下逐步地添加功能。
装饰模式角色 Component抽象组件
定义了具体组件和装饰器的共同接口可以是抽象类或接口。
ConcreteComponent具体组件
实现了抽象组件定义的接口是被装饰的原始对象。
Decorator抽象装饰器
包含一个指向具体组件的引用并实现了抽象组件定义的接口。
ConcreteDecorator具体装饰器
通过装饰器对具体组件进行扩展或修改添加额外的功能。 工作流程
首先
定义一个抽象组件Component它声明了具体组件和装饰器共同的接口方法。
其次
创建一个具体组件ConcreteComponent它实现了抽象组件的接口方法是被装饰的原始对象。
然后
创建一个抽象装饰器Decorator它也实现了抽象组件的接口方法并包含一个指向具体组件的成员变量通常为抽象组件类型用于持有被装饰的对象。
最后
创建具体装饰器ConcreteDecorator它继承自抽象装饰器并在装饰器的基础上添加了额外的功能。具体装饰器中通常会重写抽象组件的接口方法以在调用前后进行额外的处理然后再调用被装饰对象的相应方法。
Java代码实现
// Step 1: 定义抽象组件
interface Component {void operation();
}// Step 2: 创建具体组件
class ConcreteComponent implements Component {public void operation() {System.out.println(执行具体组件的操作);}
}// Step 3: 创建抽象装饰器
abstract class Decorator implements Component {protected Component component;public Decorator(Component component) {this.component component;}public void operation() {component.operation();}
}// Step 4: 创建具体装饰器
class ConcreteDecorator extends Decorator {public ConcreteDecorator(Component component) {super(component);}public void operation() {// 在调用具体组件操作前进行额外处理System.out.println(在调用具体组件操作前进行额外处理);// 调用具体组件的操作super.operation();// 在调用具体组件操作后进行额外处理System.out.println(在调用具体组件操作后进行额外处理);}
}// 使用装饰模式
public class Main {public static void main(String[] args) {// 创建具体组件对象Component component new ConcreteComponent();// 创建具体装饰器对象并将具体组件对象传入Component decorator new ConcreteDecorator(component);// 调用装饰后的操作decorator.operation();}
}代码分析
Component 是抽象组件接口ConcreteComponent 是具体组件类实现了抽象组件接口的方法。Decorator 是抽象装饰器类实现了抽象组件接口并持有一个抽象组件类型的成员变量。ConcreteDecorator 是具体装饰器类继承自抽象装饰器类并重写了操作方法在调用前后添加了额外处理。
在主函数中先创建具体组件对象ConcreteComponent然后将其传入具体装饰器对象ConcreteDecorator 的构造函数中用装饰器包装具体组件。最后调用装饰后的操作会按照一定的顺序执行额外处理和具体组件操作。
优缺点分析
优点
符合开闭原则
可以在不修改现有代码的情况下通过新增装饰器类来扩展对象的功能。
可以动态地添加/删除功能
可以根据需要动态地添加或删除对象的功能组合不同的装饰器实现不同的行为组合。
遵循单一职责原则
具体的组件类只负责核心功能具体的装饰器类只关注附加的功能各个类职责明确可维护性高。
装饰器类与具体组件类独立
装饰器类与具体组件类之间是松耦合的关系可以独立变化增加或删除装饰器不会影响其他组件的行为。
缺点
可能产生过多的具体装饰器类
如果系统中有很多功能需要扩展可能会导致产生大量的具体装饰器类增加系统的复杂性。
装饰器与组件类的接口不一致
在装饰器模式中装饰器类和具体组件类的接口不一致导致客户端需要区分调用。
总结
装饰模式提供了一种灵活的、可扩展的方式来修改对象的功能同时保持了简单的接口和代码的可维护性。但是需要权衡好扩展的复杂度和对象接口的一致性。
代理模式
代理模式是一种结构型设计模式它允许通过创建一个代理对象来控制对其它对象的访问。代理对象充当了被代理对象的接口客户端通过代理对象来访问被代理对象从而实现了对被代理对象的间接访问。
代理模式角色分析
抽象主题Subject
定义了代理对象和被代理对象的共同接口客户端通过抽象主题来访问被代理对象。
真实主题Real Subject
实现了抽象主题接口是被代理对象代理对象将对其进行间接访问。
代理Proxy
实现了抽象主题接口同时包含一个对真实主题的引用客户端通过代理对象来访问真实主题。
应用场景
远程代理
代理模式常用于网络通信中例如远程方法调用RPC。在分布式系统中客户端可以通过代理对象来调用远程服务器上的方法代理对象负责将调用请求发送到远程服务器并返回结果。远程代理隐藏了底层网络通信的细节使得客户端可以像调用本地方法一样调用远程方法。
虚拟代理
虚拟代理用于在访问对象时进行一些额外的处理。一个常见的例子是延迟加载Lazy Loading当一个对象的创建或加载非常耗费资源时可以使用虚拟代理来推迟对象的创建或加载直到真正需要访问对象时才进行。例如在图像加载时可以使用虚拟代理来延迟加载图像数据只有当需要显示图像时才真正加载图像数据。
安全代理
安全代理用于控制对对象的访问权限。例如在一个权限管理系统中可以使用安全代理来限制只有特定角色的用户才能访问某个对象。代理对象可以在访问真实对象前检查用户的角色如果用户具有访问权限则允许访问真实对象否则拒绝访问。 智能引用代理
智能引用代理用于在访问对象时添加一些额外的功能。一个常见的例子是缓存功能代理对象可以在访问真实对象前先检查缓存中是否存在对应的结果如果存在则直接返回缓存结果避免重复计算。另外还可以使用智能引用代理来实现对象池代理对象可以管理对象的创建和销毁并在访问对象时从对象池中获取对象。
总结
代理模式在许多实际应用中都有广泛的应用。通过引入代理对象可以实现对被代理对象的间接访问并可以在访问前后做一些额外的处理如网络通信、延迟加载、权限控制和功能扩展等。代理模式可以提高系统的灵活性和可扩展性同时也需要权衡系统的复杂性和性能。
Java程序实现
首先我们定义一个接口 Image表示图像对象的接口
public interface Image {void display();
}其次我们创建一个真实的图像类 RealImage实现 Image 接口表示真实的图像对象
public class RealImage implements Image {private String filename;public RealImage(String filename) {this.filename filename;loadFromDisk();}private void loadFromDisk() {System.out.println(Loading image from disk: filename);}public void display() {System.out.println(Displaying image: filename);}
}然后我们创建一个代理类 ProxyImage实现 Image 接口表示图像的代理对象
public class ProxyImage implements Image {private String filename;private RealImage realImage;public ProxyImage(String filename) {this.filename filename;}public void display() {if (realImage null) {realImage new RealImage(filename);}realImage.display();}
}最后我们可以使用代理对象来访问真实的图像对象例如
public class Main {public static void main(String[] args) {Image image new ProxyImage(test.jpg);// 第一次访问会创建真实的图像对象并显示image.display();// 第二次访问直接显示之前创建的真实图像对象image.display();}
}输出结果
Loading image from disk: test.jpg
Displaying image: test.jpg
Displaying image: test.jpg程序分析
在上面的示例中ProxyImage 类充当了代理对象它在访问真实的图像对象之前先进行了一些额外的处理。当第一次访问图像时代理对象会创建真实的图像对象并显示当第二次访问图像时代理对象直接显示之前创建的真实图像对象避免了重复加载和显示。通过代理对象我们可以实现对真实对象的间接访问并在访问前后做一些额外的处理。
优缺点分析
优点
代理模式可以实现对真实对象的间接访问可以在访问前后做一些额外的处理如权限控制、延迟加载、缓存等。 代理对象可以隐藏真实对象的具体实现细节保护真实对象的安全性。 代理模式可以提高系统的灵活性和可扩展性可以在不修改真实对象的情况下增加新的代理对象。 代理模式符合单一职责原则可以将真实对象和代理对象分离分别负责各自的功能。
缺点
由于引入了代理对象会增加系统的复杂性增加了代码的数量和维护的难度。 代理模式会引入额外的开销因为需要通过代理对象来访问真实对象可能会导致性能下降。 如果代理对象的创建和销毁过程比较复杂可能会影响系统的性能。
总结
代理模式在许多实际应用中都有广泛的应用可以提供额外的功能和保护真实对象的安全性。但是在使用代理模式时需要权衡系统的复杂性和性能确保代理对象的创建和销毁过程不会影响系统的性能。
工厂方法模式
工厂方法模式是一种创建型设计模式它定义了一个创建对象的接口但由子类决定要实例化的类是哪一个。工厂方法模式将对象的实例化推迟到子类中进行。
角色分类
抽象产品Abstract Product
定义了产品的接口是具体产品类的共同父类或接口。
具体产品Concrete Product
实现了抽象产品接口的具体类。
抽象工厂Abstract Factory
定义了创建产品的接口包含一个或多个创建产品的抽象方法。
具体工厂Concrete Factory
实现了抽象工厂接口负责实例化具体产品。
核心思想
将对象的创建与使用分离客户端通过调用工厂方法来创建对象而不是直接实例化具体产品。这样做的好处是客户端只需要知道抽象产品和抽象工厂的存在而无需关心具体产品的细节。当需要创建不同类型的产品时只需要实现对应的具体产品和具体工厂即可而不需要修改客户端的代码。 Java代码实现
假设有一个汽车工厂可以生产不同类型的汽车包括小轿车和SUV。首先定义一个抽象汽车类AbstractProduct
public abstract class Car {public abstract void drive();
}然后定义具体的小轿车类ConcreteProduct1和SUV类ConcreteProduct2它们都继承自抽象汽车类
public class SedanCar extends Car {Overridepublic void drive() {System.out.println(Driving sedan car...);}
}public class SUV extends Car {Overridepublic void drive() {System.out.println(Driving SUV...);}
}接下来定义抽象汽车工厂类AbstractFactory其中包含一个创建汽车的抽象方法
public abstract class CarFactory {public abstract Car createCar();
}然后定义具体的小轿车工厂类ConcreteFactory1和SUV工厂类ConcreteFactory2它们都继承自抽象汽车工厂类
public class SedanCarFactory extends CarFactory {Overridepublic Car createCar() {return new SedanCar();}
}public class SUVFactory extends CarFactory {Overridepublic Car createCar() {return new SUV();}
}最后在客户端代码中使用工厂方法来创建汽车对象
public class Client {public static void main(String[] args) {CarFactory factory1 new SedanCarFactory();Car sedanCar factory1.createCar();sedanCar.drive();CarFactory factory2 new SUVFactory();Car suv factory2.createCar();suv.drive();}
}输出结果为
Driving sedan car...
Driving SUV...分析
通过工厂方法模式客户端代码只需要与抽象产品和抽象工厂进行交互而无需关心具体产品的创建过程。当需要新增其他类型的汽车时只需要实现对应的具体产品和具体工厂即可而不需要修改客户端的代码实现了代码的可扩展性和可维护性。
优缺点分析
优点
符合开闭原则
工厂方法模式通过引入抽象工厂和具体工厂的概念使得系统的扩展性更好。当需要新增一种产品时只需要新增对应的具体产品和具体工厂而不需要修改已有的代码符合开闭原则。
封装了对象的创建过程
客户端只需要关心抽象产品和抽象工厂而无需关心具体产品的创建过程。具体产品的创建过程被封装在具体工厂中使得客户端代码更加简洁、可读性更高。
降低了客户端和具体产品的耦合
客户端只依赖于抽象产品和抽象工厂而不依赖于具体产品。这样可以使客户端代码与具体产品解耦提高代码的灵活性和可维护性。
可以通过配置文件等方式动态指定具体工厂类
工厂方法模式可以通过配置文件、反射等方式动态指定具体工厂类从而实现更加灵活的对象创建方式。
缺点
增加了系统的复杂度
引入抽象工厂和具体工厂的概念使得系统的结构变得更加复杂。如果系统中只有少量的产品使用工厂方法模式可能会显得过于复杂不利于维护和理解。
增加了代码的数量
工厂方法模式需要定义抽象产品、具体产品、抽象工厂、具体工厂等多个类这增加了代码的数量。对于简单的项目使用工厂方法模式可能会显得冗余。
客户端需要知道具体工厂类
客户端需要知道具体工厂类的存在这增加了客户端的依赖。如果具体工厂类的创建逻辑发生变化客户端代码也需要相应的修改。 原型模式
这是一种创建型设计模式它允许通过复制现有对象来创建新对象而无需通过实例化类来创建。它通过克隆现有对象的属性和方法来创建新对象从而避免了创建对象时的重复工作。 角色分类
抽象原型Prototype
定义了克隆方法的接口通常是一个接口或抽象类。该接口中声明了一个克隆方法用于复制原型对象。
具体原型Concrete Prototype
实现了抽象原型接口提供了克隆方法的具体实现。具体原型对象通过克隆方法创建新的对象同时复制原型对象的属性和方法。
客户端Client
通过调用克隆方法来创建新的对象。客户端可以通过克隆方法复制原型对象然后根据需要修改克隆对象的属性。
原型管理器Prototype Manager
用于管理原型对象的创建和克隆过程。原型管理器可以维护一个原型对象的注册表客户端通过原型管理器获取原型对象的克隆。
核心思想
原型对象的克隆方法通过克隆方法可以复制原型对象的属性和方法从而创建新的对象。客户端可以根据需要通过克隆方法创建新的对象并可以自由地修改克隆对象的属性。原型模式可以有效地提高对象的创建效率并使对象的创建过程更加灵活和可扩展。
Java代码实现
// 原型接口
interface Prototype {Prototype clone();
}// 具体原型类
class ConcretePrototype implements Prototype {private String name;public ConcretePrototype(String name) {this.name name;}public Prototype clone() {return new ConcretePrototype(this.name);}public void setName(String name) {this.name name;}public String getName() {return this.name;}
}// 客户端代码
public class Client {public static void main(String[] args) {// 创建原型对象Prototype prototype new ConcretePrototype(原型对象);// 克隆原型对象Prototype clone prototype.clone();// 修改克隆对象的属性((ConcretePrototype) clone).setName(克隆对象);// 输出原型对象和克隆对象的属性System.out.println(原型对象的属性 prototype.getName());System.out.println(克隆对象的属性 ((ConcretePrototype) clone).getName());}
}代码分析
在上面的示例中我们定义了一个原型接口 Prototype其中包含一个 clone 方法用于克隆原型对象。然后我们创建了一个具体原型类 ConcretePrototype实现了 Prototype 接口并在 clone 方法中返回一个新的克隆对象。
在客户端代码中我们创建了一个原型对象 prototype然后使用 clone 方法克隆了一个新的对象 clone。接下来我们修改了克隆对象的属性并输出了原型对象和克隆对象的属性。
优缺点分析
优点
简化对象的创建
原型模式通过克隆原型对象来创建新的对象避免了重复创建对象的过程提高了对象的创建效率。
隐藏对象的创建细节
客户端通过克隆方法获取新的对象无需关心对象的创建细节使得对象的创建过程对客户端透明。
支持动态添加和修改对象的属性
克隆对象可以独立于原型对象进行修改不会影响到原型对象使得对象的创建更加灵活和可扩展。
提供了一种可替代的对象创建方式
原型模式可以作为一种可替代的对象创建方式特别适用于创建复杂对象或需要大量初始化的对象。
缺点
克隆方法的实现可能较为复杂
如果对象的属性较为复杂或存在循环引用等问题实现克隆方法可能较为复杂。
克隆对象与原型对象的关系可能较为复杂
克隆对象与原型对象之间可能存在一定的关联关系需要在克隆方法中进行处理增加了代码的复杂性。
克隆对象的创建方式受限
克隆对象的创建方式受限于原型对象的结构需要保证原型对象实现了克隆方法且克隆方法能够正确地复制对象的属性。
模板方法模式
这是一种行为型设计模式用于定义算法的框架将算法的具体实现延迟到子类中。
角色分类
抽象类Abstract Class
抽象类定义了一个模板方法该方法包含了算法的框架以及一系列基本方法的调用顺序。抽象类还可以定义抽象方法、具体方法和钩子方法用于延迟具体实现或提供默认实现。
具体子类Concrete Class
具体子类继承抽象类并实现抽象方法和钩子方法。具体子类负责实现算法的具体步骤。
抽象方法Abstract Method
抽象方法是在抽象类中声明的方法由具体子类实现。抽象方法是模板方法中的基本方法用于完成算法的一部分。
具体方法Concrete Method
具体方法是在抽象类中已经实现的方法可以在模板方法中直接调用。具体方法是模板方法中的基本方法用于完成算法的一部分。
钩子方法Hook Method
钩子方法是在抽象类中有默认实现的方法子类可以选择是否覆盖。钩子方法可以用于在算法的不同阶段提供不同的行为。
核心思想
将算法的框架固定在抽象类中而将具体实现延迟到具体子类中。抽象类定义了一个模板方法该方法包含了算法的框架以及一系列基本方法的调用顺序。抽象类还可以定义抽象方法、具体方法和钩子方法用于延迟具体实现或提供默认实现。
Java代码实现
// 抽象模板类
abstract class AbstractClass {// 模板方法定义了算法的骨架public final void templateMethod() {step1();step2();step3();}// 基本方法1protected abstract void step1();// 基本方法2protected abstract void step2();// 基本方法3protected abstract void step3();
}// 具体模板类A
class ConcreteClassA extends AbstractClass {Overrideprotected void step1() {System.out.println(ConcreteClassA: Step 1);}Overrideprotected void step2() {System.out.println(ConcreteClassA: Step 2);}Overrideprotected void step3() {System.out.println(ConcreteClassA: Step 3);}
}// 具体模板类B
class ConcreteClassB extends AbstractClass {Overrideprotected void step1() {System.out.println(ConcreteClassB: Step 1);}Overrideprotected void step2() {System.out.println(ConcreteClassB: Step 2);}Overrideprotected void step3() {System.out.println(ConcreteClassB: Step 3);}
}// 测试代码
public class Main {public static void main(String[] args) {AbstractClass classA new ConcreteClassA();classA.templateMethod();System.out.println();AbstractClass classB new ConcreteClassB();classB.templateMethod();}
}输出
ConcreteClassA: Step 1
ConcreteClassA: Step 2
ConcreteClassA: Step 3ConcreteClassB: Step 1
ConcreteClassB: Step 2
ConcreteClassB: Step 3分析
在上面的示例中抽象模板类AbstractClass定义了一个模板方法templateMethod()这个方法定义了一个算法的骨架其中包含了多个基本方法step1()、step2()、step3()。具体模板类ConcreteClassA和ConcreteClassB继承自AbstractClass并实现了基本方法。
总结
模板方法模式是一种简单但非常实用的设计模式它通过将算法的框架固定在抽象类中将具体实现延迟到具体子类中提供了一种灵活而可扩展的算法设计方案。
迪米特法则
迪米特法则Law of Demeter也被称为最少知识原则Least Knowledge Principle是一种面向对象设计的原则它强调一个对象应该尽量减少与其他对象之间的相互依赖。
核心思想
尽量减少对象之间的相互依赖使对象之间的耦合度降低。具体来说它强调一个对象应该只与其直接的朋友进行交互而不与陌生的对象进行直接交互。
这里的“朋友”指 当前对象本身
一个对象可以调用自身的方法因为它对自身的结构和行为是了解的。
以参数形式传入当前对象的对象
一个对象可以调用作为参数传入的对象的方法因为它对传入的对象的结构和行为是了解的。
当前对象的成员变量直接引用的对象
一个对象可以调用它的成员变量直接引用的对象的方法因为它对成员变量引用的对象的结构和行为是了解的。
目标
降低对象之间的耦合度提高系统的可维护性、可扩展性和可复用性。通过限制对象之间的直接交互减少了对象之间的依赖关系使系统更加灵活、易于修改和测试。
遵循迪米特法则可以使系统的设计更加模块化每个对象只需要关注自身的职责而不需要了解其他对象的内部细节。这样可以降低系统的复杂性提高代码的可读性和可维护性。同时迪米特法则也有助于提高系统的可扩展性因为减少了对象之间的直接依赖新增功能时只需要修改少量的对象即可。
Java程序实现
// 定义一个学生类
class Student {private String name;public Student(String name) {this.name name;}public String getName() {return name;}
}// 定义一个班级类
class Class {private String className;private ListStudent students;public Class(String className, ListStudent students) {this.className className;this.students students;}public String getClassName() {return className;}public ListStudent getStudents() {return students;}
}// 定义一个学校类
class School {private String schoolName;private ListClass classes;public School(String schoolName, ListClass classes) {this.schoolName schoolName;this.classes classes;}public String getSchoolName() {return schoolName;}public ListClass getClasses() {return classes;}
}// 客户端代码
public class Main {public static void main(String[] args) {// 创建学生对象Student student1 new Student(Tom);Student student2 new Student(Jerry);// 创建班级对象ListStudent students new ArrayList();students.add(student1);students.add(student2);Class class1 new Class(Class1, students);// 创建学校对象ListClass classes new ArrayList();classes.add(class1);School school new School(School1, classes);// 输出学校的名称和班级的名称System.out.println(School Name: school.getSchoolName());for (Class c : school.getClasses()) {System.out.println(Class Name: c.getClassName());}// 输出班级中的学生姓名for (Class c : school.getClasses()) {for (Student s : c.getStudents()) {System.out.println(Student Name: s.getName());}}}
}程序分析
学生类、班级类和学校类之间的关系是符合迪米特法则的。学生类只与班级类有直接的关联班级类只与学校类有直接的关联而学生类和学校类之间没有直接的关联。这样可以降低对象之间的耦合度提高系统的灵活性和可维护性。
在客户端代码中我们创建了一个学校对象然后通过学校对象获取班级对象和学生对象并输出它们的信息。通过迪米特法则我们可以看到客户端代码只需要与学校类进行交互而不需要了解班级类和学生类的内部细节这样可以降低客户端代码与其他类的直接依赖使系统更加灵活和易于维护。
总结
迪米特法则强调了对象之间的松耦合设计通过减少对象之间的直接依赖提高系统的灵活性和可维护性。遵循迪米特法则可以使系统更加模块化、可扩展和易于测试。
外观模式
外观模式Facade Pattern是一种结构型设计模式它提供了一个统一的接口用于访问子系统中的一组接口。外观模式定义了一个高层接口使得子系统更容易使用。
主要目的
简化复杂系统的接口。它通过提供一个统一的接口隐藏了子系统的复杂性使得客户端可以更方便地使用系统。外观模式通过将客户端与子系统解耦提供了一个简化的接口从而降低了系统的复杂性。
角色分析
外观Facade角色
外观角色是外观模式的核心。它知道哪些子系统类负责处理请求并将客户端的请求委派给适当的子系统对象。外观角色通常是单例模式可以提供一个简单的接口隐藏了子系统的复杂性。
子系统Subsystem角色
子系统角色是外观模式中的各个子系统类。它们是实际处理请求的类完成具体的功能。外观角色将客户端的请求委派给适当的子系统对象由子系统对象完成具体的操作。
客户端Client角色
客户端角色是使用外观模式的类。它通过调用外观角色的接口来完成操作而不需要直接与子系统类交互。客户端角色只需要知道外观角色提供的简单接口无需了解子系统的复杂性。 工作原理
客户端通过调用外观角色的接口来进行操作外观角色将请求委派给适当的子系统对象子系统对象完成具体的操作并返回结果给客户端。客户端无需了解子系统的复杂性只需要通过外观角色来访问子系统。这样可以降低系统的复杂性提高系统的可维护性和可扩展性。
核心思想总结
简化接口
外观角色提供了一个简化的接口将子系统的一组接口封装起来使得客户端可以更方便地使用系统。客户端只需要调用外观角色的接口无需了解子系统的复杂性。
解耦客户端和子系统
外观模式将客户端与子系统解耦客户端只需要与外观角色交互而不需要直接与子系统类交互。这样可以降低客户端的复杂性同时也提高了系统的可维护性和可扩展性。
隐藏实现细节
外观模式将子系统的实现细节隐藏起来只暴露给客户端一个简单的接口。这样可以保护子系统的实现细节防止客户端直接访问和修改子系统的内部实现。
Java程序实现
// 子系统类A
class SubsystemA {public void operationA() {System.out.println(SubsystemA operation);}
}// 子系统类B
class SubsystemB {public void operationB() {System.out.println(SubsystemB operation);}
}// 外观类
class Facade {private SubsystemA subsystemA;private SubsystemB subsystemB;public Facade() {subsystemA new SubsystemA();subsystemB new SubsystemB();}public void operation() {subsystemA.operationA();subsystemB.operationB();}
}// 客户端类
public class Client {public static void main(String[] args) {Facade facade new Facade();facade.operation();}
}程序分析
在上面的示例中我们定义了两个子系统类 SubsystemA 和 SubsystemB它们分别实现了不同的操作。然后我们定义了一个外观类 Facade它将子系统类封装起来并提供了一个简化的接口 operation。客户端类 Client 使用外观类来完成操作而不需要直接与子系统类交互。
优缺点分析
优点
简化客户端的操作
外观模式提供了一个简化的接口隐藏了子系统的复杂性使客户端更容易使用。
解耦客户端和子系统
外观模式将客户端与子系统解耦客户端只需要与外观类进行交互不需要直接与子系统类交互降低了客户端的复杂性。
提高系统的可用性和可维护性
外观模式将子系统的实现细节封装起来保护了子系统的实现细节使系统更加稳定和可维护。
缺点
可能导致系统变得更加复杂
当系统变得复杂时外观类可能会变得庞大难以维护。
限制了灵活性
外观模式隐藏了子系统的复杂性但也限制了客户端对子系统的灵活访问。
总结
外观模式在简化客户端操作、解耦客户端和子系统、提高系统可用性和可维护性方面具有很大的优势适用于需要隐藏复杂子系统的情况。但需要注意在设计时避免外观类变得庞大和过于复杂以及权衡灵活性和封装性。
建造者模式
建造者模式是一种创建型设计模式它可以将一个复杂对象的构建过程与其表示分离使得同样的构建过程可以创建不同的表示。
角色分类
产品Product
表示被构建的复杂对象。通常包含多个部分如属性、方法等。
抽象建造者Builder
定义了构建产品的抽象方法通常包括构建各个部分的方法和返回产品的方法。
具体建造者Concrete Builder
实现了抽象建造者接口负责具体的产品构建过程。通常包含一个具体产品的实例通过构建各个部分最终返回该产品实例。
指挥者Director
负责调用具体建造者来构建产品它不知道具体的构建细节只负责调用构建方法和返回产品。 核心思想
将构建复杂对象的过程分解为多个简单的步骤通过不同的具体建造者来实现这些步骤最终由指挥者来调用具体建造者的方法来构建产品。这样可以使得构建过程更加灵活可以根据需要选择不同的具体建造者来构建不同的产品。
Java程序
// 产品类
class Product {private String part1;private String part2;public void setPart1(String part1) {this.part1 part1;}public void setPart2(String part2) {this.part2 part2;}public void show() {System.out.println(Part 1: part1);System.out.println(Part 2: part2);}
}// 抽象建造者
interface Builder {void buildPart1();void buildPart2();Product getResult();
}// 具体建造者
class ConcreteBuilder implements Builder {private Product product;public ConcreteBuilder() {product new Product();}public void buildPart1() {product.setPart1(Part 1);}public void buildPart2() {product.setPart2(Part 2);}public Product getResult() {return product;}
}// 指挥者
class Director {private Builder builder;public Director(Builder builder) {this.builder builder;}public void construct() {builder.buildPart1();builder.buildPart2();}
}// 客户端
public class Client {public static void main(String[] args) {Builder builder new ConcreteBuilder();Director director new Director(builder);director.construct();Product product builder.getResult();product.show();}
}程序分析
在上述代码中我们定义了一个产品类 Product它有两个部分 part1 和 part2。然后我们定义了一个抽象建造者接口 Builder其中包含了构建产品各个部分的方法并定义了获取最终产品的方法。接着我们实现了具体建造者 ConcreteBuilder它实现了建造者接口并具体实现了构建各个部分的方法。然后我们定义了一个指挥者 Director它负责控制建造过程通过调用建造者的方法来构建产品。最后在客户端中我们创建了一个具体建造者对象并将其传入指挥者中然后通过指挥者来构建产品并最终获取到构建好的产品并展示出来。 优缺点分析
优点
1
可以将复杂对象的构建过程与其表示分离使得同样的构建过程可以创建不同的表示。
2
可以更加精细地控制对象的构建过程灵活地添加、删除或修改构建步骤从而创建不同的产品。
3
可以避免构造方法中出现过多的参数提高代码的可读性和可维护性。
4
可以通过建造者来隐藏具体产品的实现细节只暴露统一的构建接口提高代码的封装性。
缺点
1
增加了代码的复杂性需要定义多个类和接口来实现建造者模式。
2
如果产品的组成部分变化较少或者只有一个具体建造者建造者模式可能会显得过于繁琐。
总结分析
建造者模式适用于构建复杂对象的场景通过将构建过程分解为多个步骤使得构建过程更加灵活并且可以复用相同的构建过程来创建不同的产品。然而建造者模式也会增加代码的复杂性需要权衡使用建造者模式带来的优势和缺点。 观察者模式
观察者模式Observer Pattern是一种行为型设计模式它定义了一种一对多的依赖关系让多个观察者对象同时监听某一个主题对象当主题对象发生变化时它的所有观察者都会收到通知并更新自己。 核心思想
将观察者和被观察者之间的依赖关系解耦使其彼此之间可以独立变化。被观察者只需要知道观察者实现了某个接口而不需要知道具体的观察者类同样观察者只需要知道被观察者实现了某个接口而不需要知道具体的被观察者类。
主要角色
Subject被观察者
定义了被观察者的接口包含注册观察者、移除观察者和通知观察者的方法。
ConcreteSubject具体被观察者
实现了被观察者接口维护观察者列表并在状态发生改变时通知观察者。
Observer观察者
定义了观察者的接口包含更新方法用于接收被观察者的通知。
ConcreteObserver具体观察者
实现了观察者接口具体实现更新方法在接收到被观察者的通知时进行相应的处理。
Java程序实现
// 定义观察者接口
interface Observer {void update(String message);
}// 定义被观察者接口
interface Subject {void registerObserver(Observer observer);void removeObserver(Observer observer);void notifyObservers(String message);
}// 具体观察者类
class ConcreteObserver implements Observer {private String name;public ConcreteObserver(String name) {this.name name;}Overridepublic void update(String message) {System.out.println(name received message: message);}
}// 具体被观察者类
class ConcreteSubject implements Subject {private ListObserver observers new ArrayList();Overridepublic void registerObserver(Observer observer) {observers.add(observer);}Overridepublic void removeObserver(Observer observer) {observers.remove(observer);}Overridepublic void notifyObservers(String message) {for (Observer observer : observers) {observer.update(message);}}
}// 测试代码
public class ObserverPatternExample {public static void main(String[] args) {ConcreteSubject subject new ConcreteSubject();Observer observer1 new ConcreteObserver(Observer 1);Observer observer2 new ConcreteObserver(Observer 2);subject.registerObserver(observer1);subject.registerObserver(observer2);subject.notifyObservers(Hello, observers!);subject.removeObserver(observer2);subject.notifyObservers(Observer 2 has been removed!);}
}输出结果
Observer 1 received message: Hello, observers!
Observer 2 received message: Hello, observers!
Observer 1 received message: Observer 2 has been removed!程序分析
在上述示例中我们定义了一个观察者接口Observer和一个被观察者接口Subject。具体观察者类ConcreteObserver和具体被观察者类ConcreteSubject实现了对应的接口。
优缺点分析
优点
解耦性
观察者模式可以将观察者和被观察者之间的依赖关系解耦使得它们可以独立变化。当被观察者发生变化时只需要通知观察者即可而不需要知道具体有哪些观察者存在。
可扩展性
观察者模式可以很方便地增加新的观察者而不需要修改被观察者的代码。这符合开闭原则使得系统更加灵活和可扩展。
一对多关系
观察者模式可以实现一对多的依赖关系一个被观察者可以有多个观察者。这样可以方便地实现事件监听、消息订阅等功能。 缺点
观察者过多
当观察者过多时被观察者通知观察者的时间可能会较长影响系统的性能。
循环依赖
如果观察者和被观察者之间存在循环依赖关系可能会导致系统出现问题如死锁等。
更新顺序问题
观察者模式中观察者的更新顺序是不确定的可能会导致观察者之间的依赖关系出现问题。
总结
可以提高系统的灵活性和可扩展性。但同时也需要注意观察者过多、循环依赖和更新顺序等问题以确保系统的稳定性和性能。在使用观察者模式时需要根据具体的场景和需求进行权衡和设计。
抽象工厂模式
抽象工厂模式Abstract Factory Pattern是一种创建型设计模式它提供了一种封装一组相关或相互依赖对象创建的方式而无需指定它们具体的类。
结构
抽象工厂AbstractFactory
声明一组创建产品对象的方法每个方法对应一个具体产品类的创建。
具体工厂ConcreteFactory
实现抽象工厂接口负责创建具体的产品对象。
抽象产品AbstractProduct
声明产品的共同接口所有具体产品类都实现这个接口。
具体产品ConcreteProduct
实现抽象产品接口定义具体产品的属性和行为。
适用情况
1
系统需要一组相关或相互依赖的产品对象并希望统一创建它们。
2
系统不关心具体产品的创建过程只关心产品的接口。
3
系统需要提供一个产品的类库而不想暴露具体实现。
Java程序实现
首先我们定义抽象产品接口
public interface Shape {void draw();
}然后我们定义具体产品类实现抽象产品接口
public class Circle implements Shape {Overridepublic void draw() {System.out.println(Inside Circle::draw() method.);}
}public class Rectangle implements Shape {Overridepublic void draw() {System.out.println(Inside Rectangle::draw() method.);}
}接下来我们定义抽象工厂接口
public interface ShapeFactory {Shape createShape();
}然后我们定义具体工厂类实现抽象工厂接口
public class CircleFactory implements ShapeFactory {Overridepublic Shape createShape() {return new Circle();}
}public class RectangleFactory implements ShapeFactory {Overridepublic Shape createShape() {return new Rectangle();}
}最后我们可以使用抽象工厂模式来创建具体产品对象
public class Main {public static void main(String[] args) {ShapeFactory circleFactory new CircleFactory();ShapeFactory rectangleFactory new RectangleFactory();Shape circle circleFactory.createShape();circle.draw();Shape rectangle rectangleFactory.createShape();rectangle.draw();}
}输出结果
Inside Circle::draw() method.
Inside Rectangle::draw() method.程序分析
我们定义了抽象产品接口 Shape 和具体产品类 Circle 和 Rectangle。然后我们定义了抽象工厂接口 ShapeFactory 和具体工厂类 CircleFactory 和 RectangleFactory。最后我们使用抽象工厂模式创建了具体产品对象 Circle 和 Rectangle。
优缺点分析
优点
1
提供了一种方便的方式来创建一组相关的产品对象使得客户端无需关心具体产品的创建细节只需要通过抽象接口来使用产品。
2
客户端与具体产品类解耦增强了系统的灵活性和可扩展性。可以方便地替换具体工厂类和产品类而不影响客户端的代码。
3
符合开闭原则增加新的产品族和产品等级结构时只需要添加对应的具体工厂类和产品类而不需要修改已有的代码。
缺点
1
增加了系统的复杂度和理解难度。由于抽象工厂模式涉及多个抽象接口和具体实现类需要理解和管理的类和接口较多增加了代码的复杂性。
2
当需要增加新的产品等级结构时需要修改抽象工厂接口和所有具体工厂类破坏了开闭原则。
3
当产品族中的产品种类非常多时会导致具体工厂类的数量增加增加了系统的维护成本。
状态模式
状态模式是一种行为型设计模式它允许一个对象在内部状态发生变化时改变其行为。状态模式将对象的行为封装在不同的状态类中通过改变对象的状态来改变其行为。
关键角色
上下文(Context)
上下文是一个包含状态的对象它定义了客户端与状态对象的交互接口。上下文中维护了一个指向当前状态的引用并且在运行时可以切换到不同的状态。上下文将客户端请求委派给当前状态对象处理。
抽象状态(State)
抽象状态是一个接口或抽象类它定义了状态对象的通用行为。具体状态类需要实现这个接口或继承这个抽象类并且根据具体的状态来实现相应的行为。
具体状态(Concrete State)
具体状态是实现抽象状态的具体类。每个具体状态类都代表了上下文在特定状态下的行为。具体状态类负责处理上下文的请求并在需要时切换到其他状态。
核心思想
将状态的判断和状态的行为分离使得状态的变化不影响行为的变化。通过将状态的行为封装在具体状态类中可以方便地添加新的状态或修改现有状态的行为同时也避免了状态判断的复杂性。
Java程序实现
首先我们定义一个抽象状态类 State其中包含一个处理请求的方法 handleRequest()
public abstract class State {public abstract void handleRequest();
}然后我们创建两个具体状态类 ConcreteStateA 和 ConcreteStateB它们分别实现了抽象状态类 State
public class ConcreteStateA extends State {Overridepublic void handleRequest() {System.out.println(处理请求当前状态为A);}
}public class ConcreteStateB extends State {Overridepublic void handleRequest() {System.out.println(处理请求当前状态为B);}
}接下来我们创建一个上下文类 Context其中包含一个指向当前状态的引用并提供了一个方法 setState() 用于切换状态和一个方法 request() 用于处理请求
public class Context {private State currentState;public Context() {// 初始化为初始状态currentState new ConcreteStateA();}public void setState(State state) {currentState state;}public void request() {currentState.handleRequest();}
}最后我们可以在客户端代码中使用上下文类来测试状态模式的效果
public class Client {public static void main(String[] args) {Context context new Context();// 处理请求当前状态为Acontext.request();// 切换状态为Bcontext.setState(new ConcreteStateB());// 处理请求当前状态为Bcontext.request();}
}输出结果
处理请求当前状态为A
处理请求当前状态为B分析
在上述示例中我们通过状态模式实现了一个简单的上下文对象 Context它可以根据不同的状态来处理请求。通过切换状态上下文对象可以改变其行为。这样我们可以方便地添加新的状态类或修改现有状态的行为而不需要修改客户端代码。
优缺点分析
优点
1
通过将状态的行为封装在具体状态类中可以使得状态的变化对客户端透明客户端只需要与上下文进行交互不需要关心具体的状态。
2
增加新的状态类相对容易符合开闭原则不需要修改现有的代码。
3
将状态的行为集中到具体状态类中使得代码更加清晰易于维护和扩展。
缺点
1
当状态的行为比较少或简单时使用状态模式可能会导致类的数量增加增加了代码的复杂性。
2
如果状态之间存在相互转换的复杂逻辑可能需要引入其他模式来处理状态之间的转换。
总结
状态模式是一种通过将状态的行为封装在具体状态类中使得状态的变化不影响行为的设计模式。它可以使代码更加清晰、易于维护和扩展适用于状态变化较多且状态之间的行为差异较大的场景。
适配器模式
适配器模式是一种结构型设计模式它允许将一个类的接口转换成客户端所期望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。
角色分析
目标接口Target
客户端期望的接口适配器将原始接口转换成目标接口。
源接口Adaptee
需要被适配的类或接口。
适配器Adapter
实现目标接口同时持有源接口的实例将目标接口的方法调用转发给源接口的实例。
核心思想
通过适配器将目标接口的方法调用转发给源接口的实例。这样一来客户端就可以通过目标接口来使用源接口的功能。 应用场景
当需要使用一个已经存在的类但其接口不符合需求时可以使用适配器模式。例如使用第三方库提供的接口但需要将其转换成自己系统中的接口。 当需要复用一些已经存在的类但是接口与系统的其他部分不兼容时可以使用适配器模式。例如将不同数据库的操作接口统一成一个接口。
Java程序实现
// 目标接口
interface Target {void request();
}// 源接口
class Adaptee {void specificRequest() {System.out.println(Adaptee: specificRequest);}
}// 适配器
class Adapter implements Target {private Adaptee adaptee;Adapter(Adaptee adaptee) {this.adaptee adaptee;}Overridepublic void request() {adaptee.specificRequest();}
}// 客户端代码
public class Client {public static void main(String[] args) {Adaptee adaptee new Adaptee();Target target new Adapter(adaptee);target.request();}
}输出结果
Adaptee: specificRequest这说明适配器模式成功地将不兼容的接口转换成了兼容的接口使得客户端可以使用目标接口来调用源接口的功能。
程序分析
1
在上面的示例中我们有一个目标接口Target其中定义了客户端所期望的方法request。我们还有一个源接口Adaptee其中有一个不兼容的方法specificRequest。
2
为了使得客户端可以使用Target接口来调用specificRequest方法我们创建了一个适配器Adapter实现了Target接口并持有一个Adaptee的实例。在适配器的request方法中我们将Target接口的方法调用转发给Adaptee的specificRequest方法。
3
在客户端代码中我们创建了一个Adaptee实例和一个适配器Adapter实例并将Adaptee实例传递给适配器的构造函数。然后我们使用Target接口来调用request方法实际上是调用了Adaptee的specificRequest方法。
优缺点分析
优点
1
适配器模式可以让不兼容的接口协同工作。
2
适配器模式可以复用已有的类而无需修改其源代码。
3
适配器模式可以将不同接口的类组合在一起工作。
缺点
1
适配器模式增加了系统的复杂性因为需要增加一个适配器类。
2
适配器模式可能会降低系统的性能因为需要进行额外的转换操作。
总结
适配器模式可以将不兼容的接口转换成兼容的接口使得原本无法一起工作的类可以协同工作。它是一种非常常用的设计模式可以提高系统的灵活性和可扩展性。
备忘录模式
备忘录模式Memento Pattern是一种行为型设计模式它允许在不破坏封装性的前提下捕获一个对象的内部状态并在该对象之外保存这个状态以便在需要时能将该对象恢复到原先保存的状态。 主要角色
发起人Originator
负责创建一个备忘录对象用于保存自身状态并可以使用备忘录对象来恢复自身状态。
备忘录Memento
用于存储发起人对象的内部状态可以包含多个状态属性。
管理者Caretaker
负责保存备忘录对象但不能对备忘录对象进行修改或检查。 应用场景
需要保存和恢复对象的内部状态但不希望暴露对象实现细节。需要在某个时间点保存对象的状态并在需要时恢复到该状态。需要实现撤销操作。 结构
发起人Originator 负责创建一个备忘录对象保存自身状态并可以使用备忘录对象来恢复自身状态。可以通过构造函数或者setter方法将自身状态传递给备忘录对象。备忘录Memento 用于存储发起人对象的内部状态可以包含多个状态属性。备忘录对象应该只能由发起人对象访问。管理者Caretaker 负责保存备忘录对象但不能对备忘录对象进行修改或检查。可以使用栈或列表等数据结构来保存多个备忘录对象以支持多次撤销操作。 实现步骤
在发起人类中定义一个内部类作为备忘录类该类用于保存发起人对象的状态。在发起人类中提供创建备忘录对象、恢复状态的方法。在管理者类中保存备忘录对象并提供对外的保存和获取备忘录对象的方法。在客户端中通过发起人类和管理者类来实现对对象状态的保存和恢复操作。 Java程序实现
首先我们定义发起人类Originator
public class Originator {private String state;public void setState(String state) {this.state state;}public String getState() {return state;}public Memento createMemento() {return new Memento(state);}public void restoreMemento(Memento memento) {this.state memento.getState();}
}然后定义备忘录类Memento
public class Memento {private String state;public Memento(String state) {this.state state;}public String getState() {return state;}
}接下来定义管理者类Caretaker
public class Caretaker {private Memento memento;public void saveMemento(Memento memento) {this.memento memento;}public Memento getMemento() {return memento;}
}最后我们可以在客户端中使用备忘录模式
public class Client {public static void main(String[] args) {Originator originator new Originator();originator.setState(State 1);Caretaker caretaker new Caretaker();caretaker.saveMemento(originator.createMemento());originator.setState(State 2);System.out.println(Current state: originator.getState());originator.restoreMemento(caretaker.getMemento());System.out.println(Restored state: originator.getState());}
}输出结果
Current state: State 2
Restored state: State 1程序分析
以上代码演示了备忘录模式的基本用法。发起人类Originator保存了一个状态state并提供了创建备忘录和恢复状态的方法。管理者类Caretaker负责保存备忘录对象。在客户端中我们可以通过发起人类和管理者类来实现对状态的保存和恢复操作。 优缺点分析
优点
发起人类与备忘录类解耦发起人类不需要知道备忘录类的实现细节。备忘录类对外提供只读的状态访问接口保证了状态的安全性。可以轻松实现撤销操作只需要保存多个备忘录对象并在需要时恢复到指定的状态。
缺点
如果需要保存的状态非常庞大备忘录对象的创建和恢复操作可能会消耗大量的资源。 总结
备忘录模式通过将对象的状态保存到备忘录对象中实现了状态的保存和恢复。它可以帮助我们实现撤销操作以及在需要时恢复对象的状态。备忘录模式可以提高系统的灵活性和可维护性但需要注意备忘录对象的创建和恢复操作可能会消耗较多的资源。在实际应用中我们可以根据具体的需求和场景来选择是否使用备忘录模式。
组合模式
组合模式是一种结构型设计模式它允许将对象组合成树状结构以表示“部分-整体”的层次结构。组合模式使得客户端可以统一地处理单个对象和组合对象无需区分它们的区别。
对象类型
叶节点Leaf和组合节点Composite
叶节点
它表示树的最底层的对象它们没有子节点。
组合节点
它表示树的分支节点它可以包含其他的组合节点和叶节点。
核心思想
使用一个抽象类或接口来定义组合节点和叶节点的公共操作。这样客户端可以通过调用这些公共操作来处理组合节点和叶节点而无需知道具体的节点类型。
应用场景
1
需要表示对象的部分-整体层次结构并且希望客户端能够一致地处理单个对象和组合对象的情况。
2
需要对树状结构进行递归操作例如遍历树、查找特定节点等。
3
需要动态地增加或删除树的节点。
结构图 结构图分析
在上面的结构图中Component 是组合模式的抽象类或接口定义了组合节点和叶节点共有的操作。Composite 是组合节点的具体实现它可以包含其他的组合节点和叶节点。Leaf 是叶节点的具体实现。
Java语言实现
首先我们需要定义一个抽象的组件类 Component它包含了组合节点和叶节点的公共操作
public abstract class Component {protected String name;public Component(String name) {this.name name;}public abstract void operation();public abstract void add(Component component);public abstract void remove(Component component);public abstract Component getChild(int index);
}然后我们定义组合节点类 Composite它实现了 Component 接口并包含了一个子组件列表
import java.util.ArrayList;
import java.util.List;public class Composite extends Component {private ListComponent children;public Composite(String name) {super(name);children new ArrayList();}Overridepublic void operation() {System.out.println(Composite name operation.);for (Component component : children) {component.operation();}}Overridepublic void add(Component component) {children.add(component);}Overridepublic void remove(Component component) {children.remove(component);}Overridepublic Component getChild(int index) {return children.get(index);}
}最后我们定义叶节点类 Leaf它也实现了 Component 接口但它没有子节点
public class Leaf extends Component {public Leaf(String name) {super(name);}Overridepublic void operation() {System.out.println(Leaf name operation.);}Overridepublic void add(Component component) {// 叶节点不支持添加操作}Overridepublic void remove(Component component) {// 叶节点不支持删除操作}Overridepublic Component getChild(int index) {// 叶节点没有子节点return null;}
}现在我们可以使用组合模式来创建一个树状结构并操作它
public class Main {public static void main(String[] args) {// 创建树状结构Composite root new Composite(root);Composite branch1 new Composite(branch1);Composite branch2 new Composite(branch2);Leaf leaf1 new Leaf(leaf1);Leaf leaf2 new Leaf(leaf2);Leaf leaf3 new Leaf(leaf3);root.add(branch1);root.add(branch2);branch1.add(leaf1);branch2.add(leaf2);branch2.add(leaf3);// 调用操作方法root.operation();}
}运行上述代码输出结果如下
Composite root operation.
Composite branch1 operation.
Leaf leaf1 operation.
Composite branch2 operation.
Leaf leaf2 operation.
Leaf leaf3 operation.总结
以上就是使用Java语言实现组合模式的示例代码。通过组合模式我们可以方便地处理树状结构并且客户端可以一致地处理单个对象和组合对象。
优缺点分析
优点
简化客户端代码
客户端可以一致地处理单个对象和组合对象无需区分它们的差异。
增加新的节点类型
通过继承 Component 类可以方便地增加新的节点类型而无需修改现有的代码。
方便地处理递归结构
组合模式适用于处理递归结构例如树状结构。
缺点
可能会导致设计过于一般化
组合模式将叶节点和组合节点都抽象为 Component 类可能会导致设计过于一般化不适合特定的场景。
可能会增加系统的复杂性
组合模式引入了组合节点和叶节点的层次结构可能会增加系统的复杂性。
迭代器模式
迭代器模式是一种行为型设计模式它提供了一种访问聚合对象中各个元素的方法而不需要暴露聚合对象的内部表示。迭代器模式将遍历元素的责任交给迭代器对象从而简化了聚合对象的接口。
对象分析
聚合对象Aggregate
聚合对象是包含一组元素的对象它通常提供一个创建迭代器的方法。聚合对象可以是一个集合、数组、列表等。聚合对象的主要职责是通过迭代器对象提供对元素的遍历。 迭代器对象Iterator
迭代器对象负责遍历聚合对象中的元素。它通常包含一些基本的方法如获取下一个元素、判断是否还有下一个元素等。迭代器对象可以根据具体的需求实现不同的遍历方式如正向遍历、逆向遍历等。
Java程序示例
// 聚合对象
public interface Aggregate {Iterator createIterator();
}// 具体的聚合对象
public class ConcreteAggregate implements Aggregate {private ListObject items new ArrayList();public void addItem(Object item) {items.add(item);}public Iterator createIterator() {return new ConcreteIterator(items);}
}// 迭代器对象
public interface Iterator {boolean hasNext();Object next();
}// 具体的迭代器对象
public class ConcreteIterator implements Iterator {private ListObject items;private int position 0;public ConcreteIterator(ListObject items) {this.items items;}public boolean hasNext() {return position items.size();}public Object next() {Object item items.get(position);position;return item;}
}// 使用迭代器模式
public class Main {public static void main(String[] args) {ConcreteAggregate aggregate new ConcreteAggregate();aggregate.addItem(Item 1);aggregate.addItem(Item 2);aggregate.addItem(Item 3);Iterator iterator aggregate.createIterator();while (iterator.hasNext()) {Object item iterator.next();System.out.println(item);}}
}程序分析
1
在上述示例中Aggregate 接口定义了创建迭代器的方法 createIteratorConcreteAggregate 是具体的聚合对象实现了 createIterator 方法返回具体的迭代器对象 ConcreteIterator。ConcreteIterator 实现了 Iterator 接口提供了遍历聚合对象中元素的功能。
2
在 Main 类中我们创建了一个具体的聚合对象 ConcreteAggregate添加了一些元素。然后通过 createIterator 方法创建了一个迭代器对象并使用 while 循环遍历聚合对象中的元素。
优缺点分析
优点
简化了聚合对象的接口
迭代器模式将遍历聚合对象的责任封装在迭代器对象中使得聚合对象的接口更加简洁只需要提供一个创建迭代器的方法即可。
统一的遍历方式
迭代器模式提供了一种统一的遍历方式无论聚合对象的内部结构如何变化都可以通过迭代器对象进行遍历使得客户端代码更加简洁和可读。
增加了代码的可读性和可维护性
迭代器模式将遍历逻辑封装在迭代器对象中使得代码的逻辑更加清晰易于理解和维护。
缺点
增加了系统的复杂性
引入迭代器模式会增加系统的类和对象的数量增加了系统的复杂性。
迭代器的实现可能会受到聚合对象的影响
迭代器的实现通常依赖于聚合对象的内部结构如果聚合对象的结构发生变化可能需要相应地修改迭代器的实现。
不适合对于某些特殊聚合对象的遍历
迭代器模式适用于遍历聚合对象的情况但对于某些特殊的聚合对象如树形结构可能需要使用其他遍历方式。
总结
迭代器模式通过封装遍历聚合对象的责任简化了聚合对象的接口提供了一种统一的遍历方式增加了代码的可读性和可维护性。然而迭代器模式也会增加系统的复杂性可能受到聚合对象的影响并且不适用于某些特殊聚合对象的遍历。因此在使用迭代器模式时需要权衡其优缺点根据具体情况进行选择。
单例模式
单例模式是一种创建型设计模式它保证一个类只有一个实例并提供一个全局访问点。单例模式在许多情况下都非常有用比如控制资源的访问、线程池、日志对象等。
点睛所在
控制对象的实例化过程。通常情况下我们可以通过将构造函数私有化来防止外部直接创建对象。然后我们需要提供一个静态方法来获取单例对象这个方法负责创建对象并在后续调用时返回同一个实例。
优缺点分析
优点
确保只有一个实例
单例模式可以确保一个类只有一个实例存在这样可以避免多个实例之间的冲突和资源的浪费。
全局访问点
单例模式提供了一个全局访问点使得其他对象可以方便地访问该实例避免了对象之间的耦合。
节省资源
由于单例模式只创建一个实例可以节省系统资源特别是在需要频繁创建和销毁对象的情况下可以显著提高系统的性能。
线程安全
通过合理的实现方式单例模式可以保证在多线程环境下的线程安全性。 缺点
难以扩展
由于单例模式只允许存在一个实例因此难以扩展为多个实例。如果需要创建多个实例就需要修改单例模式的实现。
对象的生命周期
由于单例模式的实例在整个程序运行期间都存在可能会导致对象的生命周期过长造成资源的浪费。
单一职责原则
单例模式将创建对象和控制访问对象的责任集中在一起违反了单一职责原则。这可能会导致单例类的职责过重不利于代码的维护和扩展。
隐藏依赖关系
单例模式可能会导致对象之间的依赖关系变得隐式使得代码的可读性和可维护性降低。
Java程序实例
实例a
public class Singleton {private static Singleton instance;private Singleton() {// 私有构造函数}public static Singleton getInstance() {if (instance null) {instance new Singleton();}return instance;}
}分析
在这个实现中我们将构造函数私有化然后提供了一个静态方法 getInstance() 来获取单例对象。在这个方法中我们首先检查实例是否已经被创建如果没有则创建一个新的实例并返回。这种实现方式被称为 “懒汉式”因为它只有在第一次调用 getInstance() 方法时才会创建实例。
但是这种实现方式并不是线程安全的。如果多个线程同时调用 getInstance() 方法可能会导致多个实例被创建。为了解决这个问题我们可以使用同步锁来保证线程安全。
实例b更安全
public class Singleton {private static Singleton instance;private Singleton() {// 私有构造函数}public static synchronized Singleton getInstance() {if (instance null) {instance new Singleton();}return instance;}
}分析
在这个实现中我们使用了 synchronized 关键字来保证线程安全。但是这种实现方式会导致性能问题因为每次调用 getInstance() 方法时都会进行同步。
优化 ——“双重检查锁定” 实现方式
public class Singleton {private static volatile Singleton instance;private Singleton() {// 私有构造函数}public static Singleton getInstance() {if (instance null) {synchronized (Singleton.class) {if (instance null) {instance new Singleton();}}}return instance;}
}分析
在这个实现中我们首先检查实例是否已经被创建如果没有则进入同步块。在同步块中我们再次检查实例是否已经被创建如果没有则创建一个新的实例。使用 volatile 关键字可以保证多线程下的可见性。
总结
单例模式在一些特定的场景下非常有用可以确保一个类只有一个实例并提供全局访问点。但是需要注意单例模式的实现方式避免出现线程安全和性能问题并权衡其优缺点来决定是否使用单例模式。
桥接模式
桥接模式是一种结构型设计模式它将抽象部分与实现部分分离使它们可以独立变化。桥接模式通过将抽象和实现分离可以实现抽象部分和实现部分的独立扩展从而提高系统的灵活性 主要角色
抽象部分
定义了抽象的接口包含了抽象方法和属性它通常是一个抽象类或接口。
实现部分
定义了具体的实现实现了抽象部分中的方法和属性它也是一个抽象类或接口。
分析
通过将抽象部分和实现部分分离使得它们可以独立变化。这样一来如果需要增加新的抽象部分或实现部分只需要扩展相应的抽象类或接口即可而不需要修改原有的代码。
核心思想
将抽象和实现解耦使得它们可以独立变化。通过桥接模式可以实现抽象部分和实现部分的独立扩展提高系统的灵活性和可扩展性。
应用场景
1
当一个类存在两个或多个独立变化的维度时可以使用桥接模式将它们分离使得它们可以独立变化。
2
当一个类需要在运行时选择不同的实现时可以使用桥接模式。
3
当一个类需要通过组合而不是继承来实现不同的行为时可以使用桥接模式。 优缺点分析
优点
1
分离抽象和实现提高了系统的灵活性和可扩展性。
2
对于客户端来说抽象部分和实现部分是透明的可以独立变化不影响客户端的使用。
3
可以通过组合来实现不同的行为避免了继承的缺点。
缺点
1
增加了系统的复杂性需要额外的抽象部分和实现部分。
2
对于小规模的系统可能会增加代码量。
总结
桥接模式是一种将抽象和实现解耦的设计模式通过将抽象部分和实现部分分离实现了抽象部分和实现部分的独立变化提高了系统的灵活性和可扩展性。
命令模式
命令模式是一种行为型设计模式它将请求封装成一个对象从而使得可以用不同的请求对客户进行参数化同时支持请求的排队、记录请求日志、撤销操作等 角色分析
命令Command
定义了执行操作的接口通常包含一个execute()方法用于执行相关操作。
具体命令ConcreteCommand
实现了命令接口具体定义了执行操作的具体逻辑。
接收者Receiver
执行命令所要求的操作是具体命令对象的业务处理对象。
调用者Invoker
负责调用命令对象执行请求通常会持有命令对象的引用。
客户端Client
创建具体命令对象并设置命令对象的接收者。 工作流程
1
客户端创建具体命令对象并设置命令对象的接收者。
2
调用者持有具体命令对象的引用并调用命令对象的execute()方法。
3
具体命令对象执行相关操作并将请求传递给接收者进行处理。
Java程序实现
// 定义命令接口
public interface Command {void execute();
}// 定义具体命令类
public class ConcreteCommand implements Command {private Receiver receiver;public ConcreteCommand(Receiver receiver) {this.receiver receiver;}public void execute() {receiver.action();}
}// 定义接收者类
public class Receiver {public void action() {System.out.println(接收者执行操作);}
}// 定义调用者类
public class Invoker {private Command command;public void setCommand(Command command) {this.command command;}public void executeCommand() {command.execute();}
}// 客户端代码
public class Client {public static void main(String[] args) {// 创建接收者对象Receiver receiver new Receiver();// 创建具体命令对象并传入接收者对象Command command new ConcreteCommand(receiver);// 创建调用者对象并设置具体命令对象Invoker invoker new Invoker();invoker.setCommand(command);// 调用者执行命令invoker.executeCommand();}
}分析
在上面的示例中定义了一个命令接口 Command具体命令类 ConcreteCommand 实现了该接口并在 execute() 方法中调用接收者对象的操作方法。
接收者类 Receiver 定义了具体的操作方法 action()。
调用者类 Invoker 持有一个命令对象并提供了 setCommand() 方法来设置具体的命令对象以及 executeCommand() 方法来执行命令。
在客户端代码中创建了接收者对象、具体命令对象和调用者对象并设置具体命令对象到调用者对象中最后调用调用者对象的 executeCommand() 方法来执行命令。
输出结果
··· 接收者执行操作 ···
优缺点分析
优点
解耦调用者和接收者
命令模式将请求封装成一个对象使得调用者不需要知道接收者的具体实现只需要通过命令对象来执行请求。这样可以降低调用者和接收者之间的耦合度提高系统的灵活性和可维护性。
支持请求的排队和记录
命令模式可以将多个命令对象放入队列中按照一定的顺序执行。这样可以实现请求的排队和调度也可以记录请求日志方便后续操作和追踪。
支持撤销操作
命令模式可以保存命令对象的状态从而支持撤销操作。通过保存命令对象的历史状态可以实现撤销和恢复操作提供更好的用户体验。
可扩展性强
命令模式可以通过新增具体命令类来扩展系统的功能而不需要修改现有的代码。这样可以保持系统的稳定性同时也方便了系统的维护和升级。
缺点
类的数量增加
引入命令模式会增加系统中的类的数量每个具体命令类都需要实现命令接口。这样可能会增加系统的复杂性降低代码的可读性。
命令的执行效率
由于命令模式需要将请求封装成对象并通过调用者来执行因此相比直接调用接收者的方法命令模式的执行效率可能会稍低。
可能引入额外的复杂性
命令模式需要设计和管理命令对象、调用者、接收者等多个角色可能会引入额外的复杂性。尤其是在处理多个命令对象之间的协作和交互时需要仔细设计和管理。
总结
命令模式在需要将请求封装成对象、支持请求的排队、记录请求日志、撤销操作等场景下非常有用。但在一些简单的场景下引入命令模式可能会增加系统的复杂性需要权衡使用。 职责链模式
职责链模式Chain of Responsibility Pattern是一种行为型设计模式它允许多个对象都有机会处理请求从而避免请求的发送者和接收者之间的耦合关系。职责链模式将请求的发送者和接收者解耦让多个对象都有机会处理请求直到其中一个对象处理成功为止。
分析
在职责链模式中通常会有一个抽象处理者Handler类它定义了处理请求的接口和一个指向下一个处理者的引用。具体处理者ConcreteHandler类实现了抽象处理者的接口负责处理特定的请求如果自己无法处理则将请求传递给下一个处理者。
角色分析
抽象处理者Handler
定义了处理请求的接口并持有下一个处理者的引用。
具体处理者ConcreteHandler
实现了抽象处理者的接口负责处理特定的请求如果无法处理则将请求传递给下一个处理者。
客户端Client
创建处理链并将请求发送给链中的第一个处理者。 优缺点分析
优点
1
降低了请求的发送者和接收者之间的耦合请求发送者无需知道具体的处理者只需将请求发送给第一个处理者即可。
2
可以动态地增加或修改处理链增强了灵活性。
3
可以将请求的处理逻辑分布到多个处理者中避免了单个处理者处理过多的责任。
缺点
1
请求可能无法被处理或者没有处理者能够处理请求需要在链的末尾设置一个默认的处理者来处理这种情况。
2
请求可能会被多个处理者都处理需要控制好处理者之间的关系避免重复处理。
应用场景
多级审批流程
例如请假审批、报销审批等每个级别的领导都有机会处理请求。
异常处理
例如在一个系统中可以通过职责链模式将不同类型的异常交给不同的处理者处理。
日志记录
例如在一个系统中可以通过职责链模式将不同级别的日志交给不同的处理者记录。
Java程序分析
首先我们需要定义抽象处理者Handler接口包含处理请求的方法和设置下一个处理者的方法
public abstract class Handler {protected Handler nextHandler;public void setNextHandler(Handler nextHandler) {this.nextHandler nextHandler;}public abstract void handleRequest(Request request);
}然后我们创建具体处理者ConcreteHandler类实现抽象处理者接口并在处理请求时判断是否能够处理该请求如果能够处理则进行处理否则将请求传递给下一个处理者
public class ConcreteHandlerA extends Handler {Overridepublic void handleRequest(Request request) {if (request.getType().equals(TypeA)) {System.out.println(ConcreteHandlerA handles the request.);} else if (nextHandler ! null) {nextHandler.handleRequest(request);}}
}public class ConcreteHandlerB extends Handler {Overridepublic void handleRequest(Request request) {if (request.getType().equals(TypeB)) {System.out.println(ConcreteHandlerB handles the request.);} else if (nextHandler ! null) {nextHandler.handleRequest(request);}}
}public class ConcreteHandlerC extends Handler {Overridepublic void handleRequest(Request request) {if (request.getType().equals(TypeC)) {System.out.println(ConcreteHandlerC handles the request.);} else if (nextHandler ! null) {nextHandler.handleRequest(request);}}
}最后我们创建客户端Client类创建处理链并将请求发送给链中的第一个处理者
public class Client {public static void main(String[] args) {Handler handlerA new ConcreteHandlerA();Handler handlerB new ConcreteHandlerB();Handler handlerC new ConcreteHandlerC();handlerA.setNextHandler(handlerB);handlerB.setNextHandler(handlerC);Request requestA new Request(TypeA);Request requestB new Request(TypeB);Request requestC new Request(TypeC);Request requestD new Request(TypeD);handlerA.handleRequest(requestA);handlerA.handleRequest(requestB);handlerA.handleRequest(requestC);handlerA.handleRequest(requestD);}
}输出结果
ConcreteHandlerA handles the request.
ConcreteHandlerB handles the request.
ConcreteHandlerC handles the request.
No handler can handle the request.分析
在这个示例中我们创建了三个具体处理者ConcreteHandlerA、ConcreteHandlerB、ConcreteHandlerC它们分别能够处理不同类型的请求。我们通过设置每个处理者的下一个处理者形成了一个处理链。当客户端发送请求时请求会从链的第一个处理者开始处理如果某个处理者能够处理该请求则进行处理否则将请求传递给下一个处理者直到找到能够处理请求的处理者为止。如果整个链都无法处理请求则输出提示信息。
中介者模式
中介者模式Mediator Pattern是一种行为型设计模式它通过将对象之间的通信封装到一个中介者对象中从而实现对象之间的松耦合。中介者模式可以减少对象之间的直接依赖提高系统的灵活性和可维护性。
分析
在中介者模式中存在一个中介者对象它封装了对象之间的通信逻辑。对象之间的通信不再直接发生而是通过中介者对象进行。当一个对象需要与其他对象进行通信时它不需要知道其他对象的具体细节只需要与中介者进行交互即可。
角色分析
抽象中介者Mediator
定义了中介者对象的接口它通常包含一个或多个抽象的通信方法用于定义对象之间的通信规则。
具体中介者ConcreteMediator
实现了抽象中介者的接口它通过协调各个同事对象来实现协作行为。
抽象同事类Colleague
定义了同事对象的接口它通常包含一个中介者对象的引用用于与中介者进行通信。
具体同事类ConcreteColleague
实现了抽象同事类的接口它与其他同事对象通过中介者进行通信。
工作过程
各个同事对象将自己的引用传递给中介者对象以便中介者对象能够与各个同事对象进行通信。 当一个同事对象需要与其他同事对象进行通信时它将请求发送给中介者对象。 中介者对象接收到请求后根据通信规则进行相应的处理并将请求转发给目标同事对象。 目标同事对象接收到请求后进行相应的处理。
优缺点分析
优点分析
1
减少了对象之间的直接依赖提高了系统的灵活性和可维护性。
2
将对象之间的通信集中到一个中介者对象中使得系统结构更加清晰。
缺点分析
1
中介者对象将承担较多的责任可能会变得复杂。
2
如果中介者对象存在过多的逻辑可能会影响系统的性能。
适用场景
1
当对象之间存在复杂的通信逻辑时可以使用中介者模式将通信逻辑集中到一个中介者对象中。
2
当对象之间的通信关系呈现网状结构时可以使用中介者模式将通信关系简化为星型结构。
Java程序分析
// 抽象中介者
interface Mediator {void sendMessage(String message, Colleague colleague);
}// 具体中介者
class ConcreteMediator implements Mediator {private Colleague colleague1;private Colleague colleague2;public void setColleague1(Colleague colleague1) {this.colleague1 colleague1;}public void setColleague2(Colleague colleague2) {this.colleague2 colleague2;}Overridepublic void sendMessage(String message, Colleague colleague) {if (colleague colleague1) {colleague2.receiveMessage(message);} else if (colleague colleague2) {colleague1.receiveMessage(message);}}
}// 抽象同事类
abstract class Colleague {protected Mediator mediator;public Colleague(Mediator mediator) {this.mediator mediator;}public abstract void sendMessage(String message);public abstract void receiveMessage(String message);
}// 具体同事类
class ConcreteColleague1 extends Colleague {public ConcreteColleague1(Mediator mediator) {super(mediator);}Overridepublic void sendMessage(String message) {mediator.sendMessage(message, this);}Overridepublic void receiveMessage(String message) {System.out.println(ConcreteColleague1 received message: message);}
}// 具体同事类
class ConcreteColleague2 extends Colleague {public ConcreteColleague2(Mediator mediator) {super(mediator);}Overridepublic void sendMessage(String message) {mediator.sendMessage(message, this);}Overridepublic void receiveMessage(String message) {System.out.println(ConcreteColleague2 received message: message);}
}// 测试类
public class MediatorPatternExample {public static void main(String[] args) {ConcreteMediator mediator new ConcreteMediator();ConcreteColleague1 colleague1 new ConcreteColleague1(mediator);ConcreteColleague2 colleague2 new ConcreteColleague2(mediator);mediator.setColleague1(colleague1);mediator.setColleague2(colleague2);colleague1.sendMessage(Hello from colleague1);colleague2.sendMessage(Hi from colleague2);}
}分析
1
在上述示例中Mediator是抽象中介者接口定义了中介者对象的通信方法。ConcreteMediator是具体中介者类实现了抽象中介者接口并通过协调各个同事对象来实现协作行为。
2
Colleague是抽象同事类定义了同事对象的接口并包含一个中介者对象的引用用于与中介者进行通信。ConcreteColleague1和ConcreteColleague2是具体同事类分别实现了抽象同事类的接口。
3
在测试类MediatorPatternExample中创建了具体中介者对象和具体同事对象并将同事对象的引用传递给中介者对象。然后通过同事对象调用sendMessage方法发送消息中介者对象根据通信规则进行处理并将消息转发给目标同事对象。最后目标同事对象接收到消息并进行处理。
输出结果
ConcreteColleague2 received message: Hello from colleague1
ConcreteColleague1 received message: Hi from colleague2
以上示例演示了中介者模式的基本实现通过中介者对象实现了对象之间的松耦合实现了对象之间的通信。总结
总结起来中介者模式通过将对象之间的通信封装到一个中介者对象中实现了对象之间的松耦合。它可以减少对象之间的直接依赖提高系统的灵活性和可维护性。中介者模式适用于对象之间存在复杂的通信逻辑或通信关系呈现网状结构的场景。
享元模式
享元模式Flyweight Pattern是一种结构型设计模式它通过共享对象来减少内存使用和提高性能。在享元模式中共享的对象被称为享元Flyweight而非共享的对象被称为外部状态Extrinsic State。
模式结构分析
享元工厂FlyweightFactory
负责创建和管理享元对象。它维护一个享元池Flyweight Pool用于存储已经创建的享元对象。
享元接口Flyweight
声明共享对象的方法可以接收外部状态作为参数。
具体享元ConcreteFlyweight
实现享元接口实现共享对象的方法。具体享元对象可以被共享和重用。
非共享具体享元UnsharedConcreteFlyweight
不可共享的具体享元对象通常不会被其他对象使用。
客户端Client
使用享元模式的对象。它通过享元工厂获取享元对象并将外部状态传递给享元对象。
工作原理
1
在客户端需要使用享元对象时首先通过享元工厂获取对象。如果对象已经存在于享元池中则直接返回该对象否则创建一个新的享元对象并加入到享元池中。
2
客户端将外部状态作为参数传递给享元对象享元对象根据外部状态进行处理完成相应的操作。
3
客户端可以同时使用多个享元对象每个对象都可以接收不同的外部状态。
适用场景
1
系统中存在大量相似对象且这些对象可以共享部分内部状态。
2
对象的创建和销毁频繁且创建和销毁对象的代价较大。
3
对象的内部状态可以被外部状态替代且外部状态可以在对象被创建之后进行修改。
优缺点分析
优点
减少内存使用
通过共享对象减少系统中的对象数量从而减少内存的使用。
提高性能
通过共享对象减少对象的创建和销毁次数提高系统的性能。
简化对象结构
将对象的内部状态和外部状态分离简化对象的结构。
缺点
对象共享可能导致线程安全问题
如果多个线程同时访问共享对象并修改其外部状态可能会导致线程安全问题。
需要额外的管理机制
为了确保对象的共享和重用需要额外的管理机制来维护享元池增加了系统的复杂性。
Java程序示例
// 享元接口
public interface Flyweight {void operation(String externalState);
}// 具体享元
public class ConcreteFlyweight implements Flyweight {private String internalState;public ConcreteFlyweight(String internalState) {this.internalState internalState;}Overridepublic void operation(String externalState) {System.out.println(Internal state: internalState);System.out.println(External state: externalState);}
}// 享元工厂
public class FlyweightFactory {private MapString, Flyweight flyweights new HashMap();public Flyweight getFlyweight(String key) {if (flyweights.containsKey(key)) {return flyweights.get(key);} else {Flyweight flyweight new ConcreteFlyweight(key);flyweights.put(key, flyweight);return flyweight;}}
}// 客户端
public class Client {public static void main(String[] args) {FlyweightFactory factory new FlyweightFactory();Flyweight flyweight1 factory.getFlyweight(key1);flyweight1.operation(state1);Flyweight flyweight2 factory.getFlyweight(key2);flyweight2.operation(state2);Flyweight flyweight3 factory.getFlyweight(key1);flyweight3.operation(state3);}
}程序分析
在上述示例中享元模式通过共享具有相同内部状态的对象来减少内存使用。FlyweightFactory负责创建和管理享元对象ConcreteFlyweight实现了享元接口并可以被共享和重用。客户端通过享元工厂获取享元对象并将外部状态作为参数传递给享元对象。
解释器模式
解释器模式是一种行为型设计模式它提供了一种解释一个语言的方式用于解析和执行特定的文法规则。该模式将一个语言表示为一个解释器该解释器可以解释语言中的表达式从而实现特定的行为。
角色分析
抽象表达式Abstract Expression
定义了一个抽象的解释操作所有的具体表达式都继承自该抽象类。
终结符表达式Terminal Expression
表示语法中的终结符即不再进行解释的表达式。
非终结符表达式Non-terminal Expression
表示语法中的非终结符该表达式可以通过递归调用其他表达式来解释。
上下文Context
包含解释器需要的一些全局信息。
客户端Client
创建和配置解释器然后调用解释器的解释方法来解释语言中的表达式。
工作原理
1
客户端创建和配置解释器并将需要解释的语言表达式传递给解释器。
2
解释器根据语法规则将表达式解释成相应的抽象语法树。
3
客户端调用解释器的解释方法解释器根据抽象语法树递归地解释表达式最终得到结果。
优缺点分析
优点
可扩展性
通过增加新的表达式类可以轻松扩展语言的语法规则。
易于实现语法规则
解释器模式将每个语法规则都封装在一个表达式类中使得每个规则的实现都相对简单。
易于修改和维护
由于解释器模式将语法规则和表达式分离因此可以独立地修改和维护每个表达式类。
缺点
复杂性
随着语法规则的增加解释器模式的复杂性也会增加维护和理解整个解释器系统可能会变得困难。
性能问题
由于解释器模式需要递归地解释表达式可能会导致性能问题特别是处理大型表达式时。
Java程序示例
首先我们定义抽象表达式接口 Expression其中包含一个解释方法 interpret
public interface Expression {int interpret(Context context);
}然后我们实现具体的终结符表达式 NumberExpression它表示一个数字
public class NumberExpression implements Expression {private int number;public NumberExpression(int number) {this.number number;}Overridepublic int interpret(Context context) {return number;}
}接下来我们实现具体的非终结符表达式 AddExpression它表示两个表达式的相加操作
public class AddExpression implements Expression {private Expression leftExpression;private Expression rightExpression;public AddExpression(Expression leftExpression, Expression rightExpression) {this.leftExpression leftExpression;this.rightExpression rightExpression;}Overridepublic int interpret(Context context) {int leftValue leftExpression.interpret(context);int rightValue rightExpression.interpret(context);return leftValue rightValue;}
}接下来我们定义上下文类 Context用于存储解释器需要的全局信息
public class Context {private MapString, Integer variables;public Context() {variables new HashMap();}public void setVariable(String name, int value) {variables.put(name, value);}public int getVariable(String name) {return variables.get(name);}
}最后我们可以在客户端中使用解释器模式
public class Client {public static void main(String[] args) {// 创建上下文Context context new Context();context.setVariable(x, 10);context.setVariable(y, 5);// 创建表达式Expression expression new AddExpression(new NumberExpression(context.getVariable(x)),new NumberExpression(context.getVariable(y)));// 解释表达式int result expression.interpret(context);System.out.println(Result: result); // 输出结果: Result: 15}
}分析
在上面的示例中我们创建了一个上下文对象并设置了两个变量 x 和 y 的值。然后我们创建了一个表达式对象该表达式对象表示将变量 x 和 y 相加的操作。最后我们调用表达式的解释方法传入上下文对象得到最终的结果并输出。
总结
解释器模式是一种用于解释和执行特定语言的设计模式。它通过将语言表示为一个解释器并使用抽象语法树来解释表达式实现了特定的行为。尽管存在一些缺点但解释器模式在某些特定场景下仍然是一个有用的设计模式。
访问者模式
访问者模式是一种行为型设计模式它允许你将算法与一个对象结构分离开来。通过这种方式可以在不改变对象结构的情况下向对象结构中添加新的操作。
角色分析
访问者Visitor和被访问者Element
访问者
定义了一组可以访问不同类型被访问者的方法
被访问者
定义了接受访问者的方法。访问者通过被访问者的接口访问被访问者并对其进行操作。
优缺点分析
优点
将数据结构与算法分离
访问者模式可以将数据结构与算法分离使得算法可以独立于数据结构而变化提高了代码的可维护性和可扩展性。
增加新的操作很容易
当需要增加新的操作时只需要增加一个新的访问者类即可不需要修改原有的代码。
增加新的数据结构很困难
当需要增加新的数据结构时需要修改所有的访问者类因此增加新的数据结构比较困难。
4
访问者模式符合单一职责原则和开闭原则 缺点
增加新的数据结构比较困难
当需要增加新的数据结构时需要修改所有的访问者类因此增加新的数据结构比较困难。
增加新的操作会导致访问者类的数量增加
当需要增加新的操作时需要增加一个新的访问者类因此访问者类的数量会增加。
3
导致系统变得复杂增加了代码的阅读难度。
4
访问者模式需要对数据结构进行抽象增加了系统的抽象性和理解难度。
总结
访问者模式适用于数据结构相对稳定但是经常需要增加新的操作的场景同时访问者模式也需要权衡系统的复杂度和可维护性。 Java程序示例
要求
为一个图形库添加一个新的功能即计算图形的面积和周长。我们可以使用访问者模式来实现这个功能。
首先我们定义一个抽象的图形类Element其中包含一个接受访问者的方法 accept()以及一个抽象的计算面积和周长的方法 calculate()。
abstract class Shape {public abstract void accept(Visitor visitor);public abstract void calculate();
}
### 然后我们定义两个具体的图形类圆形和矩形它们都继承自图形类。
java
class Circle extends Shape {private double radius;public Circle(double radius) {this.radius radius;}public double getRadius() {return radius;}public void accept(Visitor visitor) {visitor.visit(this);}public void calculate() {System.out.println(Calculating area and perimeter of circle);}
}class Rectangle extends Shape {private double width;private double height;public Rectangle(double width, double height) {this.width width;this.height height;}public double getWidth() {return width;}public double getHeight() {return height;}public void accept(Visitor visitor) {visitor.visit(this);}public void calculate() {System.out.println(Calculating area and perimeter of rectangle);}
}接下来我们定义一个访问者接口Visitor其中包含了访问圆形和矩形的方法 visit()。
interface Visitor {void visit(Circle circle);void visit(Rectangle rectangle);
}然后我们实现具体的访问者类AreaVisitor和PerimeterVisitor分别用于计算图形的面积和周长。
class AreaVisitor implements Visitor {public void visit(Circle circle) {double area Math.PI * circle.getRadius() * circle.getRadius();System.out.println(Area of circle: area);}public void visit(Rectangle rectangle) {double area rectangle.getWidth() * rectangle.getHeight();System.out.println(Area of rectangle: area);}
}class PerimeterVisitor implements Visitor {public void visit(Circle circle) {double perimeter 2 * Math.PI * circle.getRadius();System.out.println(Perimeter of circle: perimeter);}public void visit(Rectangle rectangle) {double perimeter 2 * (rectangle.getWidth() rectangle.getHeight());System.out.println(Perimeter of rectangle: perimeter);}
}最后我们可以在客户端代码中使用访问者模式来计算图形的面积和周长。
public static void main(String[] args) {ListShape shapes new ArrayList();shapes.add(new Circle(5));shapes.add(new Rectangle(3, 4));Visitor areaVisitor new AreaVisitor();Visitor perimeterVisitor new PerimeterVisitor();for (Shape shape : shapes) {shape.accept(areaVisitor);shape.accept(perimeterVisitor);}
}程序分析
在上面的代码中我们创建了一个包含圆形和矩形的列表并分别使用面积访问者和周长访问者来计算每个图形的面积和周长。 总结
访问者模式可以帮助我们将算法与对象结构分离开来提高代码的可维护性和可扩展性。在实现访问者模式时需要定义一个抽象的被访问者类和访问者接口然后实现具体的被访问者类和访问者类。在客户端代码中可以使用访问者来访问被访问者并对其进行操作。
