单例模式
单例模式是一种创建型设计模式，用于确保一个类只有一个实例，并提供一个全局的访问点来获取该实例。在单例模式中，该类负责创建自己的唯一实例，并确保任何其他对象都只能访问到这个实例。
单例模式的主要目的是限制类的实例化次数，节约系统资源，避免多个实例对同一资源的竞争或冲突。它常用于管理共享的资源，例如数据库连接、日志记录器、线程池等。
实现单例模式的一种常见方式是使用一个私有的静态变量来保存该类的唯一实例，同时提供一个公共的静态方法来获取该实例。具体的实现可以分为以下几个步骤：
- 将类的构造函数设为私有，这样其他类就无法直接实例化该类。
- 在类内部创建一个私有的静态变量，用于保存该类的唯一实例。
提供一个公共的静态方法，允许其他类访问该类的实例。如果静态变量为空，则创建一个新的实例并将其赋值给静态变量，否则直接返回现有的实例。
下面是一个简单的示例代码，展示了如何实现单例模式：
public class Singleton {
private static Singleton instance;
private Singleton() {
// 私有构造函数
}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}在上述示例中，通过将构造函数设为私有，确保了其他类无法直接实例化Singleton类。通过getInstance()方法来获取Singleton类的实例，如果实例不存在，则创建一个新的实例并将其赋值给静态变量instance，否则直接返回现有的实例。
使用单例模式时需要注意线程安全性，特别是在多线程环境下。可以通过加锁或使用双重检查锁定等方式来确保线程安全。
单例模式在许多场景中都有广泛的应用，但也需要注意滥用单例模式可能导致代码的耦合性增加，可测试性降低等问题。因此，在实际应用中需要慎重考虑是否使用单例模式，并根据具体的情况进行合理的设计。
工厂模式
工厂模式是一种创建型设计模式，用于定义一个用于创建对象的接口，让子类决定实例化哪个类。工厂模式将对象的实例化过程封装在一个工厂类中，客户端通过调用工厂类的方法来获取所需的对象，而不需要直接使用new关键字实例化对象。
工厂模式的主要目的是将对象的创建和使用分离，使代码更加灵活和可扩展。它将创建具体对象的逻辑从客户端代码中抽离出来，使客户端代码只依赖于抽象的接口或基类，而不依赖于具体的实现类。
工厂模式通常包含以下几个角色：
- 抽象产品（Abstract Product）：定义了产品的接口，是具体产品类的共同父类或接口。
- 具体产品（Concrete Product）：实现了抽象产品接口，是工厂类所创建的对象。
- 抽象工厂（Abstract Factory）：定义了创建产品的接口，声明了工厂方法。
- 具体工厂（Concrete Factory）：实现了抽象工厂接口，负责创建具体产品的实例。
下面是一个简单的示例代码，展示了如何实现工厂模式：
// 抽象产品接口
public interface Product {
void operation();
}
// 具体产品类A
public class ConcreteProductA implements Product {
@Override
public void operation() {
System.out.println("具体产品A的操作");
}
}
// 具体产品类B
public class ConcreteProductB implements Product {
@Override
public void operation() {
System.out.println("具体产品B的操作");
}
}
// 抽象工厂接口
public interface Factory {
Product createProduct();
}
// 具体工厂类A
public class ConcreteFactoryA implements Factory {
@Override
public Product createProduct() {
return new ConcreteProductA();
}
}
// 具体工厂类B
public class ConcreteFactoryB implements Factory {
@Override
public Product createProduct() {
return new ConcreteProductB();
}
}
在上述示例中，抽象产品Product定义了产品的接口，具体产品类ConcreteProductA和ConcreteProductB实现了该接口。抽象工厂Factory定义了创建产品的接口，具体工厂类ConcreteFactoryA和ConcreteFactoryB分别实现了该接口，并负责创建具体的产品实例。
客户端可以通过调用具体工厂类的方法来获取所需的产品对象，而无需关心具体产品的实现细节。
工厂模式可以根据需要灵活地增加新的产品类和工厂类，符合开闭原则，提高了代码的可扩展性和可维护性。它在实际应用中广泛用于对象的创建和初始化过程，例如创建数据库连接、日志记录器
工厂模式在实际应用中有以下几个优点：
- 封装了对象的创建逻辑：工厂模式将对象的创建过程封装在工厂类中，客户端无需关心具体的创建细节，只需要调用工厂方法即可获取所需的对象。
- 提供了良好的扩展性：通过定义抽象工厂和具体工厂，工厂模式可以轻松添加新的产品类和工厂类，符合开闭原则，代码的扩展性和可维护性都得到提高。
- 降低了耦合性：客户端只依赖于抽象工厂和抽象产品的接口，与具体的产品类和工厂类解耦，使得客户端代码更加灵活，可替换性更强。
- 代码重用：多个客户端可以共享同一个工厂对象，避免了重复创建对象的开销，提高了代码的效率和性能。
然而，工厂模式也有一些限制和注意事项：
- 增加了系统复杂性：引入工厂类和产品类的层次结构，增加了系统的复杂性，适用于较大规模或需要频繁创建对象的情况，对于简单的对象创建可以不必引入工厂模式。
- 需要预先定义产品的接口或抽象类：工厂模式要求产品必须实现一个公共的接口或继承一个抽象类，这样才能由工厂类进行统一的创建和管理。
- 不易于与其他模式组合使用：工厂模式通常独立存在，与其他设计模式的组合使用有一定的限制。
总之，工厂模式是一种常用的创建型设计模式，适用于需要封装对象创建过程、提供灵活扩展性和降低耦合性的场景。在实际应用中，需要根据具体的需求和设计考虑是否使用工厂模式，并结合实际情况进行合理的设计和实现。
建造者模式
建造者模式是一种创建型设计模式，用于将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
建造者模式的主要目的是通过一个独立的建造者类来封装对象的构建过程，客户端只需指定具体的建造者，而无需知道具体的构建细节。通过建造者模式，可以实现对复杂对象的逐步构建，灵活地组合各个部分，最终构建出一个完整的对象。
建造者模式通常包含以下几个角色：
- 产品（Product）：表示被构建的复杂对象。产品类通常具有多个组成部分，这些部分可以是具体对象或抽象对象。
- 抽象建造者（Abstract Builder）：定义了构建产品各个部分的抽象接口，一般包括设置不同部分的方法。
- 具体建造者（Concrete Builder）：实现了抽象建造者接口，负责具体产品部件的构建，并返回构建后的产品。
- 指挥者（Director）：负责安排具体建造者的构建步骤，控制建造过程的顺序。
下面是一个简单的示例代码，展示了如何实现建造者模式：
// 产品类
public class Product {
private String partA;
private String partB;
private String partC;
public void setPartA(String partA) {
this.partA = partA;
}
public void setPartB(String partB) {
this.partB = partB;
}
public void setPartC(String partC) {
this.partC = partC;
}
// 其他操作
}
// 抽象建造者
public interface Builder {
void buildPartA();
void buildPartB();
void buildPartC();
Product getResult();
}
// 具体建造者
public class ConcreteBuilder implements Builder {
private Product product;
public ConcreteBuilder() {
this.product = new Product();
}
@Override
public void buildPartA() {
product.setPartA("Part A");
}
@Override
public void buildPartB() {
product.setPartB("Part B");
}
@Override
public void buildPartC() {
product.setPartC("Part C");
}
@Override
public Product getResult() {
return product;
}
}
// 指挥者
public class Director {
public Product construct(Builder builder) {
builder.buildPartA();
builder.buildPartB();
builder.buildPartC();
return builder.getResult();
}
}
在上述示例中，产品类Product表示被构建的复杂对象，具体建造者类ConcreteBuilder实现了抽象建造者接口Builder，负责构建产品的各个部分。指挥者类Director负责安排具体建造者的构建步骤，并调用具体建造者的方法进行产品的构建。 客户端代码可以通过指挥者来构建产品，而无需知道具体的构建细节。例如：
public class Client {
public static void main(String[] args) {
Builder builder = new ConcreteBuilder();
Director director = new Director();
Product product = director.construct(builder);
// 使用构建完成的产品
System.out.println(product);
}
}建造者模式的优点包括：
- 将复杂对象的构建过程与其表示分离，使得构建过程可独立变化，可以灵活组合各个部分。
- 可以更加精细地控制对象的构建过程，根据需要构建不同的产品变体。
- 客户端代码与具体的产品类解耦，可通过指挥者和抽象建造者来构建产品，易于扩展和维护。
然而，建造者模式也存在一些限制和注意事项：
- 增加了代码的复杂性，需要定义多个类和接口。
- 适用于构建复杂对象的场景，如果产品结构简单，可以考虑其他创建型模式。
- 客户端需要明确指定具体的建造者，对于不同的产品需要创建不同的具体建造者，增加了使用的复杂性。
总之，建造者模式是一种常用的创建型设计模式，适用于构建复杂对象的场景。通过将构建过程与表示分离，实现了灵活的构建和精细的控制。在实际应用中，需要根据具体的需求和系统设计进行合理的选择和使用。
原型模式
原型模式是一种创建型设计模式，用于通过复制（克隆）现有对象来创建新对象，而无需依赖于具体类的构造函数。原型模式允许我们通过复制现有对象的属性来创建新的对象，从而避免了直接实例化对象的过程。
原型模式的核心思想是通过克隆现有对象来创建新的对象，这样就可以避免从头开始创建对象并设置其属性。原型模式分为浅克隆和深克隆两种形式。
- 浅克隆：在浅克隆中，只会克隆对象的基本数据类型属性和引用类型属性的引用，而不会复制引用类型属性的内容。因此，原始对象和克隆对象会共享引用类型属性的内容。
- 深克隆：在深克隆中，不仅会克隆对象的基本数据类型属性和引用类型属性的引用，还会递归地克隆引用类型属性的内容。因此，原始对象和克隆对象拥有完全独立的属性副本。
原型模式通常包含以下几个角色：
- 原型（Prototype）：定义了克隆方法的接口或抽象类。
- 具体原型（Concrete Prototype）：实现了克隆方法，即实现了原型接口或继承了原型抽象类。
下面是一个简单的示例代码，展示了如何实现原型模式：
// 原型接口
public interface Prototype {
Prototype clone();
}
// 具体原型类
public class ConcretePrototype implements Prototype {
private int id;
public ConcretePrototype(int id) {
this.id = id;
}
public int getId() {
return id;
}
@Override
public Prototype clone() {
return new ConcretePrototype(id);
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
ConcretePrototype prototype = new ConcretePrototype(1);
ConcretePrototype clone = (ConcretePrototype) prototype.clone();
System.out.println("原型对象的ID：" + prototype.getId());
System.out.println("克隆对象的ID：" + clone.getId());
}
}在上述示例中，原型接口Prototype定义了克隆方法clone()，具体原型类ConcretePrototype实现了原型接口并实现了克隆方法。客户端代码通过创建原型对象，然后通过克隆方法创建克隆对象。
原型模式的优点包括：
- 可以避免复杂对象的创建过程，提高对象创建的效率。
- 可以动态地添加或修改对象的属性，通过克隆来创建新的对象。
- 可以隐藏对象的创建细节，使得客户端代码与具体类解耦。
原型模式的注意事项包括：
- 克隆方法的实现：在实现克隆方法时，需要注意对引用类型属性的处理。如果希望实现深克隆，需要对引用类型属性进行递归地克隆。
- 克隆与构造函数的区别：原型模式通过克隆来创建对象，而不是通过构造函数。因此，在使用原型模式时，应注意不要与直接实例化对象混淆。
- 对象图的复杂性：如果对象的属性中包含了其他对象，那么在实现克隆方法时需要考虑这些对象的克隆过程。复杂的对象图结构可能导致克隆过程变得复杂。
- 浅克隆与深克隆的选择：根据具体的需求和业务场景，选择适合的克隆方式。如果对象的属性不涉及到引用类型或不需要独立的副本，可以使用浅克隆；如果需要保持对象及其引用类型属性的独立性，可以使用深克隆。
总之，原型模式是一种灵活且高效的创建型设计模式，通过克隆现有对象来创建新对象。它可以避免复杂对象的创建过程，提高对象创建的效率，并能动态地添加或修改对象的属性。在使用原型模式时，需要注意克隆方法的实现和对象图的复杂性，选择适合的克隆方式。
适配器模式
适配器模式是一种结构型设计模式，用于将一个类的接口转换成客户端所期望的另一个接口，使得原本由于接口不兼容而无法一起工作的类可以协同工作。
适配器模式通过引入一个适配器类来实现接口的转换。适配器类包装了一个已有类的对象，提供客户端所期望的接口方法，并将调用委托给已有类的对象进行处理。适配器模式可以通过类适配器和对象适配器两种方式来实现。
适配器模式通常包含以下几个角色：
- 目标接口（Target）：定义了客户端所期望的接口，是客户端与适配器之间的契约。
- 已有类（Adaptee）：具有不兼容接口的类，需要被适配器包装。
- 适配器（Adapter）：将已有类的接口转换成目标接口的类，通过包装已有类的对象来实现接口的转换。
下面是一个简单的示例代码，展示了如何实现适配器模式：
// 目标接口
public interface Target {
void request();
}
// 已有类
public class Adaptee {
public void specificRequest() {
System.out.println("Adaptee specific request");
}
}
// 类适配器
public class ClassAdapter extends Adaptee implements Target {
@Override
public void request() {
specificRequest();
}
}
// 对象适配器
public class ObjectAdapter implements Target {
private Adaptee adaptee;
public ObjectAdapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void request() {
adaptee.specificRequest();
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
// 使用类适配器
Target classAdapter = new ClassAdapter();
classAdapter.request();
// 使用对象适配器
Adaptee adaptee = new Adaptee();
Target objectAdapter = new ObjectAdapter(adaptee);
objectAdapter.request();
}
}在上述示例中，目标接口Target定义了客户端所期望的接口方法request()。已有类Adaptee具有不兼容的接口specificRequest()。通过类适配器和对象适配器的实现，将已有类的接口转换成目标接口。
类适配器通过继承已有类并实现目标接口的方式来实现适配器。对象适配器通过将已有类的对象作为适配器的成员变量，并实现目标接口来实现适配器。在客户端代码中，可以根据具体的需求选择使用类适配器或对象适配器。
适配器模式的优点包括：
- 可以让原本不兼容的类协同工作：适配器模式可以将不兼容的接口转换成客户端所期望的接口，使得原本由于接口不兼容而无法一起工作的类可以协同工作。
- 增加了类的复用性：通过适配器模式，可以重用已有的类，而无需修改其原有代码，只需通过适配器来实现接口的转换。
- 灵活性和扩展性：适配器模式可以动态地增加或修改适配器类，以适应不同的接口转换需求。可以在不影响现有代码的情况下扩展适配器的功能。
- 解耦客户端和已有类：适配器模式将客户端代码与已有类解耦，客户端只需要针对目标接口编程，无需关心具体的实现类。
然而，适配器模式也存在一些限制和注意事项：
- 适配器模式增加了系统的复杂性：引入适配器类会增加代码的复杂性，特别是在存在多个适配器类时，会增加系统的维护成本。
- 不适用于重构的场景：如果已有类的接口发生变化，适配器模式需要对适配器进行修改，可能会影响到其他依赖该适配器的代码。
- 需要注意适配器的选择：根据实际情况，选择类适配器还是对象适配器，并权衡它们的优缺点。
总之，适配器模式是一种常用的结构型设计模式，用于将不兼容的类的接口转换成客户端所期望的接口。通过适配器模式，可以增加类的复用性、灵活性和扩展性，并解耦客户端和已有类。在使用适配器模式时，需要注意系统的复杂性和适配器的选择，合理地应用该模式。
装饰器模式
装饰器模式是一种结构型设计模式，它允许在不改变现有对象的结构的情况下，动态地向对象添加新的行为或责任。
装饰器模式通过使用组合而不是继承的方式，将对象的行为包装在装饰器对象中。这样，每个装饰器对象都可以根据需要增加新的行为，而不影响其他对象。
装饰器模式通常包含以下几个角色：
- 抽象构件（Component）：定义了被装饰对象和装饰器对象的公共接口，可以是抽象类或接口。
- 具体构件（Concrete Component）：实现了抽象构件接口，是被装饰的原始对象。
- 抽象装饰器（Decorator）：继承或实现了抽象构件接口，并持有一个抽象构件对象的引用。
- 具体装饰器（Concrete Decorator）：扩展了抽象装饰器，并在其中添加新的行为或责任。
下面是一个简单的示例代码，展示了如何实现装饰器模式：
// 抽象构件
public interface Component {
void operation();
}
// 具体构件
public class ConcreteComponent implements Component {
@Override
public void operation() {
System.out.println("执行具体构件的操作");
}
}
// 抽象装饰器
public abstract class Decorator implements Component {
protected Component component;
public Decorator(Component component) {
this.component = component;
}
@Override
public void operation() {
component.operation();
}
}
// 具体装饰器
public class ConcreteDecoratorA extends Decorator {
public ConcreteDecoratorA(Component component) {
super(component);
}
@Override
public void operation() {
super.operation();
addedBehavior();
}
private void addedBehavior() {
System.out.println("执行具体装饰器A的附加行为");
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
Component component = new ConcreteComponent();
component.operation();
Component decoratedComponent = new ConcreteDecoratorA(component);
decoratedComponent.operation();
}
}在上述示例中，抽象构件Component定义了被装饰对象和装饰器对象的公共接口operation()。具体构件ConcreteComponent实现了抽象构件接口。抽象装饰器Decorator继承了抽象构件接口，并持有一个抽象构件对象的引用。具体装饰器ConcreteDecoratorA扩展了抽象装饰器，并在其中添加了新的行为。
客户端代码中，首先使用具体构件对象执行操作，然后使用具体装饰器对象装饰具体构件，并执行装饰后的操作。
装饰器模式的优点包括：
- 动态扩展功能：装饰器模式允许在运行时动态地添加、修改或删除对象的行为，而无需修改其原始类的代码。通过使用不同的装饰器组合，可以实现多种不同的行为组合。
- 遵循开闭原则：装饰器模式使得扩展对象的行为变得简单，同时保持了原有代码的稳定性。对于原始类的修改是封闭的，而对于新功能的添加是开放的。
- 高度灵活性：可以根据需要逐层包装对象，实现不同层次的功能组合。装饰器模式允许通过组合来构建复杂的对象行为，而无需创建大量的子类。
- 单一职责原则：装饰器模式将功能的划分更加细致，每个装饰器类只关注自己的特定功能，遵循了单一职责原则。
然而，装饰器模式也有一些注意事项：
- 可能引入过多的对象：使用过多的装饰器可能导致对象的层次结构变得复杂，增加了系统的复杂性。
- 注意装饰器的顺序：装饰器的顺序可能影响最终的行为结果，需要谨慎选择和组织装饰器的顺序。
- 不适用于所有场景：装饰器模式适用于动态添加功能的场景，但并不适用于所有情况。对于一些固定的功能扩展，更适合使用继承来实现。
总之，装饰器模式是一种灵活而强大的设计模式，通过动态地包装对象来添加新的行为或责任。它允许在不改变原有对象的结构的情况下扩展对象的功能。在使用装饰器模式时，需要注意灵活性和复杂性的平衡，选择适合的装饰器组合，并注意装饰器的顺序。
观察者模式
观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，当一个对象的状态发生改变时，它的所有依赖者都会收到通知并自动更新。
在观察者模式中，存在两个核心角色：
- 主题（Subject）：也称为被观察者或可观察对象。主题维护了一个观察者列表，并提供了添加、删除和通知观察者的方法。主题是具有状态的对象，当状态发生改变时，会通知观察者。
- 观察者（Observer）：观察者关注主题的状态变化，并在状态变化时得到通知。观察者需要实现一个更新方法，以便主题在状态变化时调用该方法进行更新。
观察者模式的实现方式可以分为推模型和拉模型两种：
- 推模型：主题在状态变化时直接将状态推送给观察者。观察者通常通过主题的方法获取状态信息。
- 拉模型：主题在状态变化时通知观察者，但观察者需要自行从主题中拉取所需的状态信息。观察者通常通过调用主题的方法来获取状态信息。
下面是一个简单的示例代码，展示了如何实现观察者模式（推模型）：
// 主题接口
public interface Subject {
void addObserver(Observer observer);
void removeObserver(Observer observer);
void notifyObservers();
}
// 具体主题
public class ConcreteSubject implements Subject {
private List<Observer> observers = new ArrayList<>();
private String state;
@Override
public void addObserver(Observer observer) {
observers.add(observer);
}
@Override
public void removeObserver(Observer observer) {
observers.remove(observer);
}
@Override
public void notifyObservers() {
for (Observer observer : observers) {
observer.update(state);
}
}
public void setState(String state) {
this.state = state;
notifyObservers();
}
}
// 观察者接口
public interface Observer {
void update(String state);
}
// 具体观察者
public class ConcreteObserver implements Observer {
private String observerState;
@Override
public void update(String state) {
observerState = state;
System.out.println("观察者状态更新为：" + observerState);
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
ConcreteSubject subject = new ConcreteSubject();
Observer observer1 = new ConcreteObserver();
Observer observer2 = new ConcreteObserver();
subject.addObserver(observer1);
subject.addObserver(observer2);
subject.setState("状态更新");
}
}在上述示例中，观察者接口Observer定义了观察者的更新方法。具体观察者ConcreteObserver实现了更新方法，并在接收到状态更新时输出观察者的状态。
客户端代码中，首先创建了一个具体主题ConcreteSubject对象，并创建了两个具体观察者ConcreteObserver对象。然后通过addObserver方法将观察者添加到主题的观察者列表中。当调用setState方法更新主题的状态时，主题会通知所有观察者进行状态更新。
观察者模式的优点包括：
- 解耦主题和观察者：主题和观察者之间是松耦合的关系，它们彼此之间并不直接依赖。主题只需要知道观察者的接口，而不需要知道具体的观察者。
- 支持广播通信：主题可以向多个观察者发送通知，实现一对多的通信模式。
- 动态添加和移除观察者：主题允许在运行时添加和移除观察者，无需修改主题或观察者的代码。
- 符合开闭原则：通过观察者模式，可以方便地添加新的观察者，而无需修改主题的代码。
然而，观察者模式也有一些注意事项：
- 主题通知观察者的顺序不确定：在观察者模式中，主题通知观察者的顺序是不确定的，观察者之间的执行顺序可能会有差异。
- 注意观察者的更新方法：观察者的更新方法应该尽量避免耗时操作，以免影响整体性能。
- 避免循环引用：当观察者和主题之间存在循环引用时，可能导致内存泄漏，需要注意避免这种情况的发生。
总之，观察者模式是一种常用的设计模式，它提供了一种一对多的通信机制，允许主题在状态变化时通知多个观察者进行更新。通过使用观察者模式，可以实现对象之间的解耦、支持广播通信，并具有灵活性和扩展性。在使用观察者模式时，需要注意观察者的更新顺序、更新方法的效率以及避免循环引用的问题。
策略模式
策略模式是一种行为型设计模式，它定义了一系列的算法，将每个算法封装在独立的策略类中，并使它们可以相互替换。通过使用不同的策略对象，可以在运行时动态地选择不同的算法来完成特定任务。
策略模式的核心思想是将算法的使用与算法的实现分离，使得它们可以独立地变化。在策略模式中，存在三个核心角色：
- 环境（Context）：环境对象持有一个策略对象的引用，并在需要使用算法时调用策略对象的方法。环境对象将具体的业务逻辑委托给策略对象进行处理。
- 抽象策略（Strategy）：抽象策略定义了策略类的接口，通常为一个接口或抽象类。它声明了策略类所支持的算法的方法。
- 具体策略（Concrete Strategy）：具体策略是抽象策略的实现，它实现了具体的算法。每个具体策略都提供了一种算法的实现。
以下是一个简单的示例代码，展示了如何使用策略模式：
// 抽象策略
public interface SortingStrategy {
void sort(int[] array);
}
// 具体策略1：冒泡排序
public class BubbleSort implements SortingStrategy {
@Override
public void sort(int[] array) {
// 冒泡排序算法实现
// ...
System.out.println("使用冒泡排序");
}
}
// 具体策略2：快速排序
public class QuickSort implements SortingStrategy {
@Override
public void sort(int[] array) {
// 快速排序算法实现
// ...
System.out.println("使用快速排序");
}
}
// 环境
public class Sorter {
private SortingStrategy strategy;
public void setStrategy(SortingStrategy strategy) {
this.strategy = strategy;
}
public void sortArray(int[] array) {
strategy.sort(array);
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
Sorter sorter = new Sorter();
SortingStrategy strategy1 = new BubbleSort();
SortingStrategy strategy2 = new QuickSort();
sorter.setStrategy(strategy1);
int[] array1 = {5, 2, 4, 6, 1, 3};
sorter.sortArray(array1);
sorter.setStrategy(strategy2);
int[] array2 = {9, 7, 8, 2, 1, 5};
sorter.sortArray(array2);
}
}在上述示例中，抽象策略SortingStrategy定义了排序算法的接口。具体策略BubbleSort和QuickSort分别实现了冒泡排序和快速排序算法在上述示例中，环境类Sorter持有一个策略对象的引用，并通过setStrategy方法设置要使用的具体策略。在调用sortArray方法时，环境对象会委托策略对象来执行具体的排序算法。
客户端代码中，首先创建了一个环境对象Sorter。然后创建了两个具体策略对象BubbleSort和QuickSort。通过调用setStrategy方法，将具体策略对象设置到环境对象中。最后调用sortArray方法来执行排序操作。
通过使用策略模式，我们可以根据需要动态地选择不同的排序算法，而不需要修改环境类的代码。这种灵活性使得策略模式在需要根据不同的情况选择不同算法的场景中非常有用。
策略模式的优点包括：
- 算法的独立性：策略模式将算法封装在独立的策略类中，使得算法可以独立于客户端和环境对象而变化。这样，新增或修改算法不会影响到其他部分的代码。
- 易于扩展：通过新增具体策略类，可以很容易地添加新的算法，而无需修改现有的代码。这符合开闭原则。
- 提高代码可读性：使用策略模式可以使代码更加清晰明了，不同的算法被封装在不同的策略类中，易于理解和维护。
策略模式也有一些注意事项：
- 策略数量过多：如果策略过多，可能会导致类的数量增加。因此，需要根据实际情况合理使用策略模式。
- 客户端需要了解策略：客户端需要了解不同的策略，并在运行时选择合适的策略。因此，策略模式适用于客户端对策略有一定了解并能进行选择的情况。
总之，策略模式是一种常用的设计模式，它将不同的算法封装在独立的策略类中，并使得这些算法可以相互替换。通过使用策略模式，可以实现算法的独立性、易于扩展和提高代码可读性。但需要注意合理使用策略模式，避免策略数量过多，并确保客户端能够了解和选择合适的策略。
模板方法模式
模板方法模式是一种行为型设计模式，它定义了一个算法的骨架，将算法中不同的步骤延迟到子类实现。模板方法模式通过在抽象类中定义算法的框架，将具体实现延迟到子类中，从而使得子类可以根据需要重新实现特定的步骤，同时保持算法的结构不变。
模板方法模式的核心思想是将算法的不变部分封装在父类中，而将可变部分交由子类去实现。在模板方法模式中，存在两个核心角色：
- 抽象类（Abstract Class）：抽象类定义了算法的骨架，其中包含一个或多个抽象方法或具体方法。抽象类通过定义模板方法来规定算法的执行顺序，同时在模板方法中调用抽象方法或具体方法，完成算法的各个步骤。
- 具体类（Concrete Class）：具体类是抽象类的子类，它实现了抽象方法或具体方法，完成算法中的具体步骤。每个具体类都可以根据需要重新实现抽象方法，以满足特定的需求。
以下是一个简单的示例代码，展示了如何使用模板方法模式：
// 抽象类
public abstract class AbstractClass {
public void templateMethod() {
// 调用抽象方法或具体方法
step1();
step2();
step3();
}
protected abstract void step1();
protected abstract void step2();
protected void step3() {
// 默认实现
System.out.println("执行默认步骤3");
}
}
// 具体类1
public class ConcreteClass1 extends AbstractClass {
@Override
protected void step1() {
System.out.println("执行具体步骤1（ConcreteClass1）");
}
@Override
protected void step2() {
System.out.println("执行具体步骤2（ConcreteClass1）");
}
}
// 具体类2
public class ConcreteClass2 extends AbstractClass {
@Override
protected void step1() {
System.out.println("执行具体步骤1（ConcreteClass2）");
}
@Override
protected void step2() {
System.out.println("执行具体步骤2（ConcreteClass2）");
}
@Override
protected void step3() {
System.out.println("执行具体步骤3（ConcreteClass2）");
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
AbstractClass abstractClass1 = new ConcreteClass1();
abstractClass1.templateMethod();
AbstractClass abstractClass2 = new ConcreteClass2();
abstractClass2.templateMethod();
}
}
在上述示例中，抽象类AbstractClass定义了算法的框架，并实现了模板方法templateMethod。模板方法中调用了抽象在上述示例中，抽象类AbstractClass定义了算法的框架，并实现了模板方法templateMethod。模板方法中调用了抽象方法step1、step2和具体方法step3。具体类ConcreteClass1和ConcreteClass2继承了抽象类，并根据需要实现了不同的步骤。
客户端代码中，创建了具体类的实例，并调用它们的模板方法来执行算法。在运行时，根据具体类的不同，算法的具体步骤也会有所不同。
通过使用模板方法模式，可以将算法的不变部分抽象出来，并将可变部分交给子类实现。这样可以避免代码的重复，提高代码的复用性和扩展性。模板方法模式适用于有一定的算法框架，但其中某些步骤需要根据实际情况进行定制的场景。
模板方法模式的优点包括：
- 提高代码复用性：将算法的框架抽象到父类中，可以在多个子类中共享相同的算法骨架，避免代码的重复。
- 提供扩展点：将可变的部分延迟到子类中实现，使得子类可以根据需要定制算法的具体步骤，从而扩展或修改算法的行为。
- 简化算法的变更：通过修改抽象类或添加新的子类，可以很方便地修改或扩展算法的实现，而不需要修改客户端代码。
模板方法模式也有一些注意事项：
- 控制算法的结构：需要确保算法的结构稳定，不易被子类误修改。可以使用钩子方法来控制算法的执行流程。
- 理解好抽象类和具体类的职责：抽象类负责定义算法的框架和模板方法，具体类负责实现具体的步骤。需要避免在具体类中改变算法的结构。
总之，模板方法模式是一种常用的设计模式，它通过定义算法的骨架和抽象方法，将算法的具体实现延迟到子类中。模板方法模式提供了一种灵活的方式来定义算法的框架，并允许子类根据需要定制算法的具体步骤。通过使用模板方法模式，可以提高代码复用性、提供扩展点，并简化算法的变更。
迭代器模式
迭代器模式是一种行为型设计模式，它提供了一种顺序访问聚合对象中各个元素的方法，而无需暴露聚合对象的内部表示。迭代器模式将遍历和操作分离，使得迭代过程更加简单和灵活。
在迭代器模式中，存在以下几个核心角色：
- 迭代器（Iterator）：迭代器定义了访问和遍历聚合对象中元素的接口，包括获取下一个元素、判断是否还有元素等方法。
- 具体迭代器（Concrete Iterator）：具体迭代器实现了迭代器接口，在具体聚合对象中迭代元素，并跟踪当前迭代位置。
- 聚合对象（Aggregate）：聚合对象定义了创建相应迭代器的接口，即工厂方法。它可以是一个集合、列表、数组等数据结构。
- 具体聚合对象（Concrete Aggregate）：具体聚合对象实现了聚合对象接口，返回相应的具体迭代器。
以下是一个简单的示例代码，展示了如何使用迭代器模式：
// 迭代器接口
public interface Iterator {
boolean hasNext();
Object next();
}
// 具体迭代器
public class ConcreteIterator implements Iterator {
private List<Object> items;
private int position = 0;
public ConcreteIterator(List<Object> items) {
this.items = items;
}
@Override
public boolean hasNext() {
return position < items.size();
}
@Override
public Object next() {
if (hasNext()) {
Object item = items.get(position);
position++;
return item;
}
return null;
}
}
// 聚合对象接口
public interface Aggregate {
Iterator createIterator();
}
// 具体聚合对象
public class ConcreteAggregate implements Aggregate {
private List<Object> items = new ArrayList<>();
public void addItem(Object item) {
items.add(item);
}
@Override
public Iterator createIterator() {
return new ConcreteIterator(items);
}
}
// 客户端代码
public class Client {
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);
}
}
}在上述示例中，迭代器模式被用于遍历聚合对象ConcreteAggregate中的元素。具体聚合对象通过实现Aggregate接口，并返回具体迭代器ConcreteIterator来创建迭代器。迭代器实现了Iterator接口，提供了遍历聚合对象中元素的方法。
在客户端代码中，创建了具体聚合对象ConcreteAggregate并添加了多个元素。通过调用createIterator方法创建具体在客户端代码中，创建了具体聚合对象ConcreteAggregate并添加了多个元素。通过调用createIterator方法创建具体迭代器ConcreteIterator。然后，使用迭代器的hasNext方法判断是否还有下一个元素，使用next方法获取下一个元素并进行操作。
迭代器模式的优点包括：
- 简化聚合对象的接口：迭代器模式将遍历和操作分离，使得聚合对象的接口更加简洁，只需要提供一个创建迭代器的方法即可。
- 支持多种遍历方式：通过定义不同的迭代器，可以支持不同的遍历方式，例如正向遍历、反向遍历、按条件过滤等。
- 封装遍历算法：迭代器模式封装了遍历算法，客户端无需关心具体的遍历实现，只需要通过迭代器进行访问即可。
- 支持并发迭代：迭代器模式可以实现对聚合对象的安全并发访问，不需要额外的同步措施。
迭代器模式也有一些注意事项：
- 聚合对象的变化：在遍历过程中，如果聚合对象发生变化（例如增加或删除元素），需要注意迭代器的同步问题，可以考虑使用快照迭代器或使用更高级的并发迭代器。
- 遍历顺序的确定性：迭代器模式并没有规定遍历聚合对象的顺序，具体的遍历顺序由具体迭代器实现决定。
总之，迭代器模式通过提供统一的访问接口，将聚合对象的遍历和操作解耦，使得聚合对象的遍历过程更加简单和灵活。它可以简化聚合对象的接口，支持多种遍历方式，并封装了遍历算法，提高了代码的可维护性和扩展性。迭代器模式在许多应用中都得到了广泛的应用，例如集合类、数据库查询等场景。
组合模式
组合模式是一种结构型设计模式，它允许将对象组合成树形结构来表示部分-整体的层次关系，使得用户对单个对象和组合对象的使用具有一致性。
在组合模式中，存在以下几个核心角色：
- 组件（Component）：组件是组合中的抽象类或接口，它定义了组合对象和叶子对象的公共行为，包括添加、删除、获取子节点等方法。
- 叶子节点（Leaf）：叶子节点是组合的基本元素，它没有子节点。叶子节点实现了组件接口，并定义了自己的行为。
- 组合节点（Composite）：组合节点是具有子节点的节点，它实现了组件接口，并可以包含其他组合节点或叶子节点。组合节点通过递归方式实现了组合对象的行为。
以下是一个简单的示例代码，展示了如何使用组合模式：
// 组件接口
public interface Component {
void operation();
}
// 叶子节点
public class Leaf implements Component {
private String name;
public Leaf(String name) {
this.name = name;
}
@Override
public void operation() {
System.out.println("Leaf " + name + " operation");
}
}
// 组合节点
public class Composite implements Component {
private List<Component> children = new ArrayList<>();
public void add(Component component) {
children.add(component);
}
public void remove(Component component) {
children.remove(component);
}
@Override
public void operation() {
for (Component component : children) {
component.operation();
}
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
Component leaf1 = new Leaf("Leaf 1");
Component leaf2 = new Leaf("Leaf 2");
Component leaf3 = new Leaf("Leaf 3");
Composite composite1 = new Composite();
composite1.add(leaf1);
composite1.add(leaf2);
Composite composite2 = new Composite();
composite2.add(leaf3);
composite2.add(composite1);
composite2.operation();
}
}在上述示例中，使用组合模式创建了一个树形结构。叶子节点Leaf表示树的基本元素，组合节点Composite表示具有子节点的节点。通过组合节点的嵌套，形成了层次化的组合对象。
在客户端代码中，创建了多个叶子节点和组合节点，并使用add方法将它们组合在一起。然后，调用组合节点的operation方法，实现对整个组合对象的操作。通过组合模式，客户端可以一致地对待单个对象和组合对象，无需关心对象的具体类型。
组合模式的优点包括：
- 简化客户端代码：组合模式提供了一致的操作接口，客户端无需区分单个对象和组合对象，可以简化客户端代码简化客户端代码：组合模式提供了一致的操作接口，客户端无需区分单个对象和组合对象，可以简化客户端代码。
- 增加新的组件类型更容易：通过扩展组件接口和实现类，可以很容易地增加新的组件类型，而无需修改现有的代码。
- 提供了灵活性和可扩展性：组合模式使得树形结构的组合对象可以无限扩展，可以随时添加、删除或替换子节点。
- 使得整体和部分之间的关系更加清晰：组合模式通过树形结构清晰地表示了整体和部分之间的关系，使得用户可以更好地理解和处理对象之间的层次关系。
然而，组合模式也有一些注意事项：
- 可能会导致设计过于一般化：在应用组合模式时，需要仔细考虑对象的公共行为和特定行为之间的平衡，以避免过于一般化的设计。
- 可能会带来性能问题：当组合对象层次较深且节点数量较大时，可能会对性能产生一定影响，需要进行合理的优化。
总之，组合模式通过将对象组合成树形结构，使得用户对单个对象和组合对象的使用具有一致性。它简化了客户端代码，增加新的组件类型更容易，提供了灵活性和可扩展性，并清晰地表示了整体和部分之间的关系。组合模式在需要处理具有层次结构的对象集合时非常有用，例如文件系统、UI组件等。
43万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
