建造者

3 月，跳不动了？>>> 建造者模式（Builder Pattern）是将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建创建不同的表示，属于创建型模式。 建造者模式的设计有四个角色； 1、产品：要创建的产品类对象 2、建造者抽象：建造者的抽象类，规范产品对象的各个组成部分的构建，一般由子类实现具体的监造过程。 3、建造者：具体的Builder类，根据不同的业务逻辑，具体化对象的各个组成部分的创建。 4、调用者：调用具体的建造者，来创建对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。 优点： 1、封装性好，创建和使用分离 2、扩展性好，建造类之间独立，一定程度上解耦。 缺点： 1、产生多余的Builder对象， 2、产品内部发生变化，建造者都要修改，成本较大。 应用场景： 1、相同的方法、不同的执行顺序，产生不同的结果时。 2、多个部件或零件，都可以装配到一个对象中，但是产生的结果又不相同。 3、产品类非常复杂，或者产品类中的调用顺序不同产生不同的作用。 4、当初始化一个对象特别复杂，参数多，而且很多参数都具有默认值时。 代码示例： @Data public class BuilderEntiry { private String name; private Integer age; private List

3 月，跳不动了？>>> 1 概述 前面我们说了 工厂模式 和 抽象工厂模式 ，下面来说说 建造者模式 。 建造者模式 也是一种极为常见的 创建型模式 ，前面提到的两类 工厂 模式隐藏了类的属性与构造细节，而 建造者模式 通过 Builder 类，适当地暴露了类的属性，使得类的创建更具有灵活性和可读性。 2 建造者模式 当一个类的构造函数包含很多参数，或者参数之间有很多种组合(如肯德基的套餐)，调用构造函数来创建类将会变得不方便，可读性也很差。对于多种组合的情况， 工厂模式 也将变得不适用。 在这种情况下， 建造者模式 提供了一种思路，通过将类的创建委托给 建造器 (Builder)，将类的创建与表示分离，大大地简化了类创建的复杂度。 3 案例 考虑做一个 Pizza ，为方便起见，让它只包含尺寸，底，馅以及是否加芝士四个属性。看看如何用 建造者模式 来创建： public class Test { public static void main(String[] args) { Pizza.Builder pizzaBuilder = new Pizza.Builder(); Pizza pizza = pizzaBuilder.size(6) .crustType(Pizza.CrustType.THIN) .topping("Durian") .build(); pizza

一、概念：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 二、UML示意图： 在上图中，定义了一个抽象Builder类并且定义了两个个抽象方法BuildPart()，具体Builder类继承这个抽象builder类并提供BuildPart()方法的实现，这里在不同情形下可能会有多个BuildPart方法，他们代表着这个要构建这个对象需要做的具体工作，但是如果组织执行这些具体工作，以什么顺序执行这些具体工作，则是由Director类决定，Director类在Construct方法中实现了对builder类的实例多个BuildPart工作的组织和顺序调用，通过这个方法就能够使用Builder对象创建出一个正确的Product。 三、优缺点 优点： 客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。 每一个具体建造者都独立，因此可以方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象 ，而无需修改原代码，符合开闭原则。 可以更加精细地控制产品对象的创建过程 。将复杂产品对象的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。 缺点： 若产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

建造者模式(Builder) 建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。 介绍 意图： 将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。 主要解决： 主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。 何时使用： 一些基本部件不会变，而其组合经常变化的时候。 如何解决： 将变与不变分离开。 关键代码： 建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。 应用实例： 1、去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"。 优点： 1、建造者独立，易扩展。 2、便于控制细节风险。 缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。 使用场景： 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。 注意事项： 与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。 建造者模式一般认为有四个角色: 1

建造者模式 定义： 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示 作用： 在用户不知道对象的建造过程和细节的情况下，可以直接创建复杂的对象 优点： 产品的建造和表示分离，实现了解耦。使用建造者模式可以使客户端不必要知道产品内部组成的细节 将复杂产品的创建步骤分截在不同的方法中，使得创建过程更加清晰 具体的建造者之间使相互独立的，这有利于系统的扩展。增加新的具体建造者无需修改原有类库的代码，符合”开闭原则“。 缺点： 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似；如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。 应用场景： 需要生成的产品对象有复杂的内部结构，这些产品对象具有共性 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品 适合于一个具有较多的零件（属性）的产品（对象）的创建过程 1、测试案例一 先设想一个场景：工程师修建房子，并且他知道他需要做的工作是打地基、铺电线、打钢筋、粉刷墙壁以及最终得到房子，但是他不会自己做，这个具体的事情由工人完成，他只是负责指挥工人完成相应的工作。 这段话里面含有四个对象： 工程师：建造出来的房子、口头上的命令工作 抽象的工作（口头上的工作）

场景: 　　我们需要建造一个复杂的产品。比如：神舟飞船、iphone。这些复杂的产品创建。有这样一个问题需要处理：装配这些子组件是不是有个步骤问题？ 　　在实际开发中，什么所需要的对象构建时，也非常复杂，有很多步骤需要处理时。 　　 建造模式的本质： 　　分离了对象子组件的单独构造（由Builder来负责）和装配（由Director负责）。从而可以构造出复杂的对象。这个模式适用于：某个对象的构建过程复杂的情况下使用。 由于实现了构建和装配的解耦。不同的构建器，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构建算法与装配算法的解耦，实现了更好的复用。 下面用建造飞船的例子来说明： 　　//创建飞船类和对应的模块类 package com.note.pattern.build; //飞船类 public class AirShip { private OrbitalModule orbitalModule;// 轨道舱 private Engine engine;// 发动机 private EscapeTower escapeTower;// 逃逸塔 public void launch() { System.out.println("发射！"); } public OrbitalModule getOrbitalModule() {

本系列博客是自己在学习设计模式过程中收集整理的文章集合，其他文章参看 设计模式传送门 建造者模式简介 建造者模式是一种创建型设计模式，这种模式具有很好的封装性。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。 其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。 建造者模式通常包含以下角色 抽象建造者类（builder）：为创建product对象而指定各个组件的抽象接口 具体建造类（concreteBuilder）：实现builder接口，重写方法构建不同的表示 产品类（product）：具体的产品 指挥者类（director）：构建一个使用builder接口的对象 JDK中的建造者模式——StringBuilder StringBuilder 类是JDK中比较典型的建造者模式的体现

本系列博客是自己在学习设计模式过程中收集整理的文章集合，其他文章参看 设计模式传送门 本文是转载文章 ，原文请参见 设计模式（九）——建造者模式 概念 建造者模式（英：Builder Pattern）是一种创建型设计模式，又名：生成器模式。GOF 给建造者模式的定义为：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。这句话说的比较抽象，其实解释一下就是：将建造复杂对象的过程和组成对象的部件解耦。 用途 假设现在我们是一家网游设计公司，现在我们要”抄袭”梦幻西游这款游戏，你是该公司的游戏角色设计人员。你怎么设计出该游戏中的各种角色呢？ 在梦幻西游来中包括人、仙、魔等种族的角色，而每种不同的种族的角色中又包含龙太子、逍遥生等具体的角色。 作为一个出色的开发人员，我们设计的角色生成系统应该包含以下功能和特性： 为了保证游戏平衡，所有角色的基本属性应该一致 因为角色的创建过程可能很复杂，所以角色的生成细节不应该对外暴露 随时可以新增角色 对某个具体角色的修改应该不影响其他角色 其实，对于角色的设计，我们可以使用抽象工厂模式，将同一种族的角色看成是一个产品族。但是，这样做可能存在一个问题，那就是我们可能要在每个角色的创建过程中都要从头到尾的构建一遍该角色。比如一个角色包含头部、身体。其中头部又包括脸部、和其他部位。其中脸部又包含眉毛、嘴巴、鼻子等部位

建造者模式 定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以产生不同的表示 1. 应用场景 复杂对象中，相同的方法，不同的执行顺序，会产生较大的差异。希望能够按不同的顺序调用对象的方法。 复杂对象的组成部分时常可能发生变化，但组装方法类似。比如零食套餐搭配，电脑的配置搭配等。 2.五个组成部分 抽象产品类 定义产品具体业务逻辑方法和一个调度方法，该调度方法可以控制各个业务逻辑方法的执行顺序或者产品类的组成部分。可以设置一个集合存储方法执行顺序或者零件类型。 具体产品类 产品类实现具体业务逻辑的方法。 差异性很大的产品不适合使用建造者模式。产品类通常可以结合模板方法模式。 抽象建造者 一个抽象方法设置产品的不同组成部分或者设置不同方法的执行顺序。 一个抽象方法构建产品并返回 具体的建造者 继承抽象建造者，每个类型的产品都需要一个具体的建造者。该类返回一个对应的产品 导演类 调度不同的建造者，来建造出不同的产品。场景类只需要和导演类打交道 类图如下（此处产品类是模板方法模式的类图）： 3.案例模拟 需求：现在需要组装两种车，宝骏和宝马，两者组装顺序不同。宝马：底盘->轮子->车身->座椅,宝骏：底盘->车身->座椅->轮子,还有进化版的宝骏，不要轮子，直接就能飞，敞篷宝马，不要车身，底盘轮子座椅直接开 先创建一个抽象产品类和两个实现的产品类宝骏和宝马产品

将一个复杂对象的构建过程与它的表示分离, 使得同样的构建过程可以创建不同的表示，属于创建型模式。 特征: 只需指定需要建造的类型就可以获得对象, 建造过程及细节不需要了解。属于创建型模式 使用场景: 创建对象需要很多步骤, 但是步骤的顺序不一定固定。如果一个对象有非常复杂的内部结构(很多属性), 可以将复杂对象的创建和使用进行分离。 @Data public class Course { private String name ; private String ppt ; private String video ; private String note ; private String homework ; } public class CourseBuilder { private Course course = new Course() ; public CourseBuilder addName (String name) { course .setName(name) ; return this; } public CourseBuilder addPPT (String ppt) { course .setPpt(ppt) ; return this; } public CourseBuilder addVideo (String video) { course