Java建造者设计模式详解

建造者模式(Builder):将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
使用场景:

  • 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
  • 当构造过程必须允许被构造的对象有不同的表示时。

通用类图:

举例:我们生活当中有许多设备都是以组装的形式存在的,例如台式电脑,那么有些厂商就会推出一些具有默认配置的组装电脑主机(这里可以用到模板方法模式来实现),顾客可以购买默认配置的产品,也可以要求厂商重新组装一部不同配置不同组装方式的主机。此时,我们就可以使用建造者模式来满足特殊顾客的要求了。
注意到这个例子中厂商是重新组装一部主机,即关注点是主机的每个组成部分,这就符合上面Builder模式给出的使用场景了。
简单代码实现如下:

//抽象产品类,使用了模板方法模式,不同产品有不同的“组成部分part”
abstract class AbstractProduct{
 protected abstract void part01();
 protected abstract void part02();
 protected abstract void part03(); 

 //模板方法给出了默认的组装方式,生成默认的产品
 public final AbstractProduct defaultProduct() {
 part01();
 part02();
 part03();
 return this;//返回当前对象,即默认组装方式的产品
 }
} 

//具体的产品A、B,不同产品实现了不同的“组成部分part”
class ConcreteProductA extends AbstractProduct{
 protected void part01() {
 System.out.println("产品A :part01() ...");
 }
 protected void part02() {
 System.out.println("产品A :part02() ...");
 }
 protected void part03() {
 System.out.println("产品A :part03() ...");
 }
} 

class ConcreteProductB extends AbstractProduct{
 protected void part01() {
 System.out.println("产品B :part01() ...");
 }
 protected void part02() {
 System.out.println("产品B :part02() ...");
 }
 protected void part03() {
 System.out.println("产品B :part03() ...");
 }
} 

//抽象建造者,制定每一种产品应该实现的组合方式buildPart()和生产buildProduct()的标准
abstract class AbstractBuilder{
 public abstract void buildPart();
 public abstract AbstractProduct buildProduct();
} 

/*
* 具体建造者,如果对于默认产品(即当调用抽象产品中的defaultProduct()方法)不满意时,
* 可以不调用它来获得产品,而是使用具体的建造者来改变产品的生产组装方式,以得到不同的产品
*/
class ConcreteBuilderA extends AbstractBuilder{
 private AbstractProduct productA = new ConcreteProductA(); 

 public void buildPart() {
 this.productA.part03();
 this.productA.part02();
 this.productA.part01();
 } 

 public AbstractProduct buildProduct() {
 return this.productA;
 }
} 

class ConcreteBuilderB extends AbstractBuilder{
 private AbstractProduct productB = new ConcreteProductB(); 

 public void buildPart() {
 this.productB.part02();
 this.productB.part01();
 //特地省略掉产品B中的一个组成部分,例如该部分的功能顾客不需要
// this.productB.part03();
 } 

 public AbstractProduct buildProduct() {
 return this.productB;
 }
} 

//导演类,预先持有各个产品的建造者,为需要不同于默认产品的用户提供不同的组装方式
class Director{
 private AbstractBuilder builderA = new ConcreteBuilderA();
 private AbstractBuilder builderB = new ConcreteBuilderB(); 

 public AbstractProduct getProductA() {
 this.builderA.buildPart();
 return this.builderA.buildProduct();
 } 

 public AbstractProduct getProductB() {
 this.builderB.buildPart();
 return this.builderB.buildProduct();
 }
} 

//测试类
public class Client {
 public static void main(String[] args) {
 System.out.println("利用模板方法模式获得默认的产品A");
 AbstractProduct defualtProductA = new ConcreteProductA().defaultProduct(); 

 System.out.println("\n利用Director类获得不同组装方式的产品A");
 Director director = new Director();
 director.getProductA(); 

 System.out.println("\n利用Director类获得不同组装方式的产品B");
 director.getProductB();
 }
}

测试结果:
利用模板方法模式获得默认的产品A
产品A :part01() ...
产品A :part02() ...
产品A :part03() ...
利用Director类获得不同组装方式的产品A
产品A :part03() ...
产品A :part02() ...
产品A :part01() ...
利用Director类获得不同组装方式的产品B
产品B :part02() ...
产品B :part01() ...

其实在这个例子当中,产品类那一部分用到了上一篇文章讲到的模板方法模式,即defaultProduct()提供了一个产品的默认组成部分的组装方式。

但是这里我有个疑问,AbstractProduct类中根据模板方法模式提供的的所谓默认组装方式只是打印出几句测试的话而已,又不是真正返回一个具体产品,但是上面例子中那样返回一个当前对象(return this;)的处理方式不知道是否合理?

另外,在写了这几篇关于用Java代码实现设计模式的文章之后,发现这个建造者Builder模式似乎是结合了抽象工厂模式、模板方法模式。上面一段已经说过我的疑惑,至于抽象工厂模式,我个人是觉得上面代码例子中的Director类就很类似抽象工厂的具体工厂类了,但是Director类还要负责build一下产品的组装方式才返回一个产品,也许就是这个“build一下”才显得建造者模式关注于产品各个部分的组装,而抽象工厂模式仅仅只是关注于一个最终产品的生成。

之前看过一句话说大概是说:计算机方面的任何一个问题如果难以解决,都可以通过增加一个中间层来处理。现在想了一下,好像Abstract Factory和Builder模式都是运用了这一“原理”来达到想要的效果。譬如Abstract Factory中有个抽象工厂类,Builder中有个Director类,说到底也就是封装隐藏某些细节,并从实现和使用这两者之间解耦出来吧。

我认为,一定要先理解了各个模式的关注点和适用场景之后才能更好地把握这些吧。

可能这几个模式都是创建型的模式而且我没有什么实战经验才会使得我对于这些有点混淆了...不怕,在它们全部实现的过程中一点点思考,慢慢地运用到实际当中去应该就会逐渐明白的了。

以上就是本文的全部内容,希望对大家的学习有所启发。

(0)

相关推荐

  • 实例讲解Java设计模式编程中的OCP开闭原则

    定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.          开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统.开闭原则可能是设计模式六项原则中定义最模糊的一个了,它

  • java设计模式系列之装饰者模式

    何为装饰者模式 (Decorator)? 动态地给一个对象添加一些额外的职责.就增加功能来说,Decorator 模式相比生成子类更为灵活. 一.结构 Component : 定义一个对象接口,可以给这些对象动态地添加职责. interface Component { public void operation(); } ConcreteComponent : 实现 Component 定义的接口. class ConcreteComponent implements Component { @

  • Java设计模式编程之工厂方法模式的使用

    定义:定义一个用于创建对象的接口,让子类决定实例化哪一个类,工厂方法使一个类的实例化延迟到其子类. 类型:创建类模式 类图: 工厂方法模式代码 interface IProduct { public void productMethod(); } class Product implements IProduct { public void productMethod() { System.out.println("产品"); } } interface IFactory { publ

  • 深入解析Java的设计模式编程中建造者模式的运用

    定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. 类型:创建类模式 类图: 四个要素 产品类:一般是一个较为复杂的对象,也就是说创建对象的过程比较复杂,一般会有比较多的代码量.在本类图中,产品类是一个具体的类,而非抽象类.实际编程中,产品类可以是由一个抽象类与它的不同实现组成,也可以是由多个抽象类与他们的实现组成. 抽象建造者:引入抽象建造者的目的,是为了将建造的具体过程交与它的子类来实现.这样更容易扩展.一般至少会有两个抽象方法,一个用来建造产品,一个是用来返回

  • 举例说明Java设计模式编程中ISP接口隔离原则的使用

    Interface Segregation Principle,ISP接口隔离原则主张使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法

  • 理解java设计模式之建造者模式

    建造者模式(Builder Pattern)主要用于"分步骤构建一个复杂的对象",在这其中"分步骤"是一个稳定的算法,而复杂对象的各个部分则经常变化.因此, 建造者模式主要用来解决"对象部分"的需求变化. 这样可以对对象构造的过程进行更加精细的控制. package com.shejimoshi.create.Builder; /** * 功能:意图是将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示 * 适用性: * 当创

  • Java观察者设计模式详解

    观察者模式(有时又被称为发布(publish )-订阅(Subscribe)模式.模型-视图(View)模式.源-收听者(Listener)模式或从属者模式)是软件设计模式的一种.在此种模式中,一个目标物件管理所有相依于它的观察者物件,并且在它本身的状态改变时主动发出通知.这通常透过呼叫各观察者所提供的方法来实现.此种模式通常被用来实现事件处理系统. 观察者模式(Observer)完美的将观察者和被观察的对象分离开.举个例子,用户界面可以作为一个观察者,业务数据是被观察者,用户界面观察业务数据的

  • 理解Java设计模式编程中的迪米特原则

    定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合.          自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的.          迪米特法则又叫最少知道原则,最早是在1987年

  • 简单理解遵循接口隔离原则的Java设计模式编程

    定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接口I中的方法1.方法4.方法5,类D是

  • 简单讲解Java设计模式编程中的单一职责原则

    单一职责原则:一个类,只有一个引起它变化的原因. 为什么需要单一职责原则? 如果一个类有多个原因要去修改它,那么修改一个功能时,可能会让其他功能产生Bug,所以一个类最好只有一个职责.但实际应用中还是比较难实现的,我们只能是尽量符合这个原则. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下面是个例子: packag

  • 详解Java设计模式编程中的中介者模式

    定义:用一个中介者对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使耦合松散,而且可以独立地改变它们之间的交互. 类型:行为类模式 类图: 中介者模式的结构        中介者模式又称为调停者模式,从类图中看,共分为3部分:  抽象中介者:定义好同事类对象到中介者对象的接口,用于各个同事类之间的通信.一般包括一个或几个抽象的事件方法,并由子类去实现. 中介者实现类:从抽象中介者继承而来,实现抽象中介者中定义的事件方法.从一个同事类接收消息,然后通过消息影响其他同时类. 同事类

随机推荐