定义
创建者模式(Builder Pattern),又称建造者模式,是一种创建型设计模式,它提供了一种创建对象的最佳方式。该模式允许将一个复杂对象的构建与它的表示分离,这样同样的构建过程可以创建不同的表示。创建者模式通常使用一个指挥者(Director)类,它指导构建过程,以及一个或多个建造者(Builder)类,它们用于实现具体的构建步骤。
应用场景
创建者模式适用于以下场景:
- 当一个对象需要多个部分组合在一起,并且对象的组合需要满足一定的构造过程时。
- 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
- 当构造过程允许被构造的对象有不同的表示时。
示例
假设我们需要创建一个复杂的Meal
对象,它由Drink
、MainCourse
和Dessert
组成。我们可以使用创建者模式来逐步构建这个Meal
对象。
// 产品类
class Meal {private String drink;private String mainCourse;private String dessert;// getters and setters...
}// 抽象建造者
abstract class MealBuilder {protected Meal meal;public Meal getMeal() {return meal;}public void createNewMeal() {meal = new Meal();}public abstract void buildDrink();public abstract void buildMainCourse();public abstract void buildDessert();
}// 具体建造者
class ItalianMealBuilder extends MealBuilder {public void buildDrink() {meal.setDrink("Red Wine");}public void buildMainCourse() {meal.setMainCourse("Pizza");}public void buildDessert() {meal.setDessert("Gelato");}
}class JapaneseMealBuilder extends MealBuilder {public void buildDrink() {meal.setDrink("Sake");}public void buildMainCourse() {meal.setMainCourse("Sushi");}public void buildDessert() {meal.setDessert("Mochi");}
}// 指挥者
class Director {private MealBuilder mealBuilder;public Director(MealBuilder mealBuilder) {this.mealBuilder = mealBuilder;}public Meal construct() {mealBuilder.createNewMeal();mealBuilder.buildDrink();mealBuilder.buildMainCourse();mealBuilder.buildDessert();return mealBuilder.getMeal();}
}// 客户端代码
public class Client {public static void main(String[] args) {MealBuilder builder = new ItalianMealBuilder();Director director = new Director(builder);Meal meal = director.construct();// 使用meal对象...}
}
原则间的权衡与冲突
创建者模式遵循了几个软件设计原则:
- 单一职责原则:通过将复杂对象的创建过程从其表示中分离出来,创建者模式使得同一个构建过程可以创建不同的表示。
- 开闭原则:如果需要引入新的类型的对象,无需修改现有的指挥者和客户端代码,只需添加一个新的建造者类即可。
然而,如果对象的构建过程相对简单,或者不需要多样化的表示,使用创建者模式可能会导致不必要的复杂性。
设计模式的局限性
- 复杂性:对于简单对象,使用创建者模式可能会导致设计变得过于复杂。
- 性能开销:创建者模式中的多个步骤可能会导致性能开销,特别是在对象创建的热点路径中。
总结与建议
创建者模式非常适合构建复杂对象,尤其是当对象需要多个部分以特定顺序组合时。然而,如果对象的构造过程简单,或者不需要独立的表示,则应该避免使用创建者模式,以免增加不必要的复杂性。在决定是否使用创建者模式时,应该考虑当前和未来的需求,如果预计对象的构建将变得复杂,或者可能需要多种表示,则使用创建者模式可能是一个明智的选择。