建造者模式

也叫生成器模式，他是一个创立型模式

通用类图

Product产品类

通常是实现了模板办法模式，也就是有模板办法和根本办法.

public class Product {   public void doSomething(){     //独立业务解决  }}

Builder形象建造者

标准产品的组建，个别是由子类实现。例子中的CarBuilder就属于 形象建造者。

public abstract class Builder {   //设置产品的不同局部，以取得不同的产品  public abstract void setPart();   //建造产品   public abstract Product buildProduct();}

ConcreteBuilder具体建造者

实现抽象类定义的所有办法，并且返回一个组建好的对象。例子中 的BenzBuilder和BMWBuilder就属于具体建造者。

public class ConcreteProduct extends Builder {   private Product product = new Product();   //设置产品整机  public void setPart(){    /* * 产品类内的逻辑解决 */   }   //组建一个产品   public Product buildProduct() {    return product;   }}

Director导演类

负责安顿已有模块的程序，而后通知Builder开始建造，在下面的例 子中就是咱们的老大，××公司找到老大，说我要这个或那个类型的车辆 模型，而后老大就把命令传递给我，我和我的团队就开始拼命地建造， 于是一个我的项目建设结束了。

public class Director {  private Builder builder = new ConcreteProduct();  //构建不同的产品   public Product getAProduct(){    builder.setPart();    /* * 设置不同的整机，产生不同的产品 */    return builder.buildProduct();  }}

定义

将一个简单对象的构建和他的示意拆散，使得同样的构建过程能够创立不同的示意。

特色

用户只须要指定须要建造的类型就能够取得对象，建造过程及细节不须要理解

实用场景

一个对象有非常复杂的内部结构（很多属性）

咱们能够把简单对象的创立和应用拆散

能够不必关怀谁先谁后了
  • 雷同的办法，不同的执行程序，产生不同的事件后果时，能够采纳建造者模式。
  • 多个部件或整机，都能够拆卸到一个对象中，然而产生的运行后果又不雷同时，则能够应用该模式。
  • 产品类非常复杂，或者产品类中的调用程序不同产生了不同的效 能，这个时候应用建造者模式十分适合。
  • 在对象创立过程中会应用到零碎中的一些其余对象，这些对象在产品对象的创立过程中不易失去时，也能够采纳建造者模式封装该对象的创立过程。该种场景只能是一个弥补办法，因为一个对象不容易取得，而在设计阶段居然没有察觉，而要通过创建者模式柔化创立过程， 自身曾经违反设计的最后指标。

案例

  • JPA
  • mybatis example

案例类图

以后执行的程序由具体的构建者来决定，用户只须要关怀须要的内容

  • 如果你要调用类中的成员变量或办法，须要在后面加上this关键字，不加也能失常地跑起来，然而不清晰，加上this要害 字，我就是要调用本类中的成员变量或办法，而不是本办法中的一个变 量。
  • 还有super办法也是一样，是调用父类的成员变量或者办法，那就加上这个关键字，不要省略，这要靠束缚，还有就是程序员的自觉性，他要是死不悔改，那咱也没招。

源码中的提现

StringBuilder

public AbstractStringBuilder append(String str) {  if (str == null)    return appendNull();  int len = str.length();  ensureCapacityInternal(count + len);  str.getChars(0, len, value, count);  count += len;  return this;}@Overridepublic StringBuilder append(char c) {  super.append(c);  return this;}
  • 过程凋谢给用户
  • 后果程序来帮咱们管制程序

Mybatis CacheBuilder

public CacheBuilder addDecorator(Class<? extends Cache> decorator) {  if (decorator != null) {    this.decorators.add(decorator);  }  return this;}public Cache build() {  setDefaultImplementations();  Cache cache = newBaseCacheInstance(implementation, id);  setCacheProperties(cache);  // issue #352, do not apply decorators to custom caches  if (PerpetualCache.class.equals(cache.getClass())) {    for (Class<? extends Cache> decorator : decorators) {      cache = newCacheDecoratorInstance(decorator, cache);      setCacheProperties(cache);    }    cache = setStandardDecorators(cache);  } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {    cache = new LoggingCache(cache);  }  return cache;}

Mybatis SqlsessionFactoryBuilder

public SqlSessionFactory build(Reader reader, String environment) {  return build(reader, environment, null);}public SqlSessionFactory build(Reader reader, Properties properties) {  return build(reader, null, properties);}public SqlSessionFactory build(Reader reader, String environment, Properties properties) {  try {    XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);    return build(parser.parse());  } catch (Exception e) {    throw ExceptionFactory.wrapException("Error building SqlSession.", e);  } finally {    ErrorContext.instance().reset();    try {      reader.close();    } catch (IOException e) {      // Intentionally ignore. Prefer previous error.    }  }}

Spring beanDefinitionBuilder

public AbstractBeanDefinition getBeanDefinition() {  this.beanDefinition.validate();  return this.beanDefinition;}public static BeanDefinitionBuilder genericBeanDefinition(String beanClassName) {  BeanDefinitionBuilder builder = new BeanDefinitionBuilder(new GenericBeanDefinition());  builder.beanDefinition.setBeanClassName(beanClassName);  return builder;}public static BeanDefinitionBuilder genericBeanDefinition(Class<?> beanClass) {  BeanDefinitionBuilder builder = new BeanDefinitionBuilder(new GenericBeanDefinition());  builder.beanDefinition.setBeanClass(beanClass);  return builder;}

总结

长处

  • 封装性好，创立和应用拆散
  • 扩展性好，建造类之间互相独立,容易扩大

  • 便于管制细节危险

    • 因为具体的建造者是独立的，因而能够对建造过程逐渐细化，而不对其余模块产生任何影响

毛病

  • 产生多余的Builder对象
  • 产品外部发生变化，建造者都要批改，老本较大

和别的设计模式的区别

和工厂模式的区别

  • 建造者更加关怀办法的调用程序，工厂模式重视于创建对象

    • 建造者模式关注的是整机类型和拆卸工艺(程序)，这是它与工厂办法模式最大不同的中央，尽管同为创立类模式，然而重视点不同。
  • 创建对象的力度不同，建造者模式创立简单的对象，由各种简单的部件组成，工厂模式创立进去的都一样

  • 关注点不一样

    • 工厂模式只有把对象创立进去就行了
    • 建造者岂但须要创立，还须要理解这个对象由什么部件组成
  • 建造者模式依据建造过程的程序不一样，最终的对象部件组成也不一样

问题

什么状况下应该思考到应用建造模式？
  • 雷同的办法，不同的执行程序会产生不同的后果的时候须要用到
  • 产品类非常复杂，或者产品类的调用程序不同产生了不同的效力
  • 对象穿件的过程会用到一些其余对象，对象在创立的过程中不容易失去
我的笔记仓库地址gitee 快来给我点个Star吧