[cv]123这里替换成需要评论可见的内容[/cv]

(http://www.wchulian.com.cn/content/uploadfile/202207/31231657455509.png)

简单工厂模式

# 概述：他根据提供的参数不同返回不同的类型，专门定义一个工厂核心类去创建
# 其他类的对象，只需要提供相应的参数给这个核心工厂类的某个办法就能创建相应
# 的对象，而且被创建的对象通常都有共同的父类

抽象产品类（抽象类或者接口）
产品具体类 （继承或实现）抽象产品类
简单工厂核心类（根据业务传来的参数创建对应的对象）

优点：
当你需要什么，只需要要传入一个正确的参数,就可以获取你所需要的对象，也无需知道对应的类名，只需要知道对应的参数就行，也无须知道其创建细节。
通过引入配置类，无需修改代码就可以创建产品具体类对象

缺点：
1、2模式最大的问题在手工厂类的职责相对过重,增加新的产品需要修改工厂类的判断逻辑，增加一个 else if(条件)，
、2这一点与开闭原则是相违背的。
3、工厂核心类集中所有类的实例创建，一旦这个类不能正常使用，整个系统都受影响
4、扩展困难，一旦新增新产品就必须改工厂类。不符合开闭原则
5、最重要的还是影响继承关系，例如父类有A办法输出A，子类B继承A并且覆盖A办法输出B,
父类 aa= new 子类();
aa.A（）；输出的是A字符集  而不是B,正常清空下输出B,
因为工厂模式使用了静态工厂办法，所以无法覆盖

当然
子类 aa= new 子类();
输出的是B字符集 这个是正常的

工厂模式（工厂办法模式）多态工厂模式（工厂类实现同一个父类）

概述：他根据简单工厂进行优化，使之支持开闭原则，工厂抽象类是提供创建产品对象的接口，
而它的子类只负责生产某一种产品，这样就将产品对象的创建转移到工厂子类中完成。

抽象产品类 （抽象类或者接口）
产品具体类 （继承或实现）抽象产品类
抽象工厂类 （抽象类或者接口）负责定义创建产品对象的公共接口
具体工厂类 （继承或实现）抽象工厂类 负责生产具体产品某种对象（只生产一种产品
例如只生产华为手机，就不能生产其他，因为每个工厂对应某一种产品）

它跟简单工厂最大区别就是符合了开闭模式，
它将工厂核心类核心抽象化，让每个具体工厂实现抽象工厂

1.工厂方法模式的优点
(1) 给客户用来创建所需产品对象，同时隐藏了所需产品对象实例化的细节，用户只需要怎么使用，不需要知道实现细节，
   用户只需要知道产品所对应的工厂具体类就行了，不需要知道产品的类名
(2）他能自主确定工厂创建何种对象，而如何创建这个对象的细节则完全封装在具体工厂内工厂方法模式，
    之所以又被称为多态工厂模式,是因为所有的具体工厂类都具有同一些父类。
(3）系统新增新产品时候，无需修改抽象工厂具体类和抽象工厂接口,也无须修改客户端，也无须修改其他的具体工厂和具体产品，仅仅只要加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符“开闭原则”。

2.工厂方法模式的缺点
(1)在添加新产品时，不仅仅需要提供产品具有实现类，还需要提供抽象工厂具体实现类，因此系统文件个数会变多，维护和阅读，扩展会带来一定的压力，而且更多的类需要编译和运行也会给系统带来额外的开销
(2)将工厂核心类进行抽象化会增加理解难度。
(3)每种工厂具体实现类只能生产一种产品

抽象工厂模式

概述：由于简单工厂的具体实现类只能创建一种产品的对象（例如一旦创建华为手机，就不能创建华为电脑），具有唯一性，但是一般情况下，一个工厂不会只创建一种产品，例如华为工厂不会只创建华为手机，还能创建华为电脑，华为手表，华为笔记本，
因此抽象工厂就是让一个工厂能创建一个产品族（多种产品）的对象，还不是只创建一个产品等级结构（一种产品）对象
产品族：一般情况下产品族就等价于一个工厂，例如一个华为产品族（华为工厂）不可能只创建华为手机，它还能创建华为电脑，华为路由器，华为笔记本等等，这些产品的集合就是一个产品族，一个工厂具体类就只为一个产品族服务
产品等级结构：就是产品的继承结构，例如接口也就是父类是电视工厂，那么它的子类（具体实现抽象类）就是该父类的电视品牌，例如华为电视，联想电视，海尔电视，这些都是它的子类，每种品牌电视都是子类，也都是一个产品等级结构

抽象产品类 （抽象类或者接口）
产品具体类 （继承或实现）抽象产品类
抽象工厂类 （抽象类或者接口）
具体工厂类 （继承或实现）抽象工厂类

1.抽象工厂模式的优点
(1) 给客户用来创建所需产品对象，同时隐藏了所需产品对象实例化的细节，用户只需要怎么使用，不需要知道实现细节，也就是他隔离了具体产品类的对象的生成细节，客户完全不知道该对象什么时候生成，怎么生成。同时我们变换一个工厂具体实现类就变得很简单，而且由于工厂具体实现类实现父类抽象工厂类，我们只需要更改该父类就能改变系统的行为，可以实现高内聚低耦合。
(2）他能保证该具体实现工厂类只生产某产品族的产品，例如只生产华为产品族的产品（华为收，华为电脑、、、、）

2.抽象工厂模式的缺点
(1)具有局限性，例如如果我们要原来的产品族添加产品，例如华为工厂一开始只生产华为手机，华为电脑，我们现在想生产华为手表，这样我们就需要更改工厂具体实现类的代码，这样就不符合开闭原则
因为说抽象工厂具有开闭原则的倾斜行就是这个意思

建造者模式

概述：将一个复杂对象的构建与它的表示分离，使得相同的构建过程，可以创建不同的产品对象，
它是一步步的创建一个复杂的对象，用户不需要知道具体的创建细节
当我们需要来之同一个类，但是要就有不同结构对象时，就可以通过构造另一个建造者来进行实列化。

Product(产品类) :我们具体需要生成的类对象 javaBean 
Builder(抽象建造者类)：为我们需要生成的类对象，构建不同的模块属性，即：公开构建产品类的属性，隐藏产品类的其他功能
ConcreteBuilder(具体建造者类)：实现我们要生成的类对象
Director(导演类)：确定构建我们的类对象具体有哪些模块属性，在实际应用中可以不需要这个角色，直接通过client处理

建造者模式的优缺点如下：
优点：
1.封装性好，将一个复杂对象的构建和该对象的表示分离。
2.扩展性好，各个具体的建造者相互独立，有利于系统的解耦。
3.客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产
生任何影响，便于控制细节风险。
缺点：
1.产品的组成部分必须相同，这限制了其使用范围。
2.如果产品的内部变化复杂，如果产品内部发生变化，则建造者也要同步修改，后期维护成本较大

优点
建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。

在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。

可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。

其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点
建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。
再回到之前的需求，看看我们是否都满足？

由于建造角色的过程比较复杂，其中还有相互依赖关系（如脸部依赖于头部），所以我们使用建造者模式将将建造复杂对象的过程和组成对象的部件解耦。这样既保证了基本属性全都一致（这里的一致指的是该包含的应该全都包含）也封装了其中的具体实现细节。

同时，在修改某个具体角色的时候我们只需要修改对应的具体角色就可以了，不会影响到其他角色。

如果需要新增角色，只要再增加一个具体建造者，并在该建造者中写好具体细节的建造部分代码就OK了。

建造者模式的优缺点
优点
建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。

在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。

可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。

其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点
建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

适用环境
在以下情况下可以使用建造者模式：

说到抽象工厂模式和建造者模式的区别

我们举个例：
就拿王者荣耀来说创建影响角色来说   ，衣服，头部，身体，脚，衣服，名字等等属性 ，不同觉得顶多是属性赋值不一样
但是办法都差不多一样，例如饮料办法，一个赋值可乐，因为赋值咖啡，办法都一样就是值不同，
所以他们也一样，如果使用了抽象工厂代理模式，将同一种族的角色看成是一个产品族。但是，这样做可能存在一个问题，那就是我们可能要在每个角色的创建过程中都要从头到尾的构建一遍该角色。比如一个角色包含头部、身体。其中头部又包括脸部、和其他部位。其中脸部又包含眉毛、嘴巴、鼻子等部位。整个角色的创建过程是极其复杂的。很容易遗漏其中的某个步骤。

我们可以看到，建造者模式与工厂模式是极为相似的，总体上，建造者模式仅仅只比工厂模式多了一个”指挥者”的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，那么图中剩余的部分就可以看作是一个简单的工厂模式了。

与工厂模式相比，建造者模式一般用来创建更为复杂的对象，因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类——导演类。

也就是说，工厂模式是将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；而建造者模式中，建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。

建造者模式与工厂模式类似，适用的场景也很相似。一般来说，如果产品的建造很复杂，那么请用工厂模式；如果产品的建造更复杂，那么请用建造者模式。哈哈哈。。。

总结
建造者模式将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

在建造者模式的结构中引入了一个指挥者类，该类的作用主要有两个：一方面它隔离了客户与生产过程；另一方面它负责控制产品的生成过程。指挥者针对抽象建造者编程，客户端只需要知道具体建造者的类型，即可通过指挥者类调用建造者的相关方法，返回一个完整的产品对象。