抽象工厂模式

我选择的设计模式是抽象工厂模式。 工厂方法模式的一个重大缺陷： 一个工厂子类只能创建一个产品子类 抽象工厂模式的出现就是为了解决这一难题： 其特点是抽象工厂中每个工厂可以创建多种产品子类 主要用途： 允许使用抽象的接口来创建一组相关产品，而不需要知道该产品具体是什么， 使用步骤： 1创建抽象工厂类，定义具体工厂的公共接口 2创建抽象产品族类，定义抽象产品的公共接口 3创建产品类，（继承抽象产品族类，定义具体产品的公共接口） 4创建具体产品类（继承产品类，定义具体的生厂产品） 5创建具体工厂类（继承抽象工厂类，创建客户所需要产品） 6客户端通过实例化具体的工厂类，并调用其方法创建不同的产品 相比工厂方法模式，该抽象工厂模式多了一个产品族类，将产品进行分类，这样在一个具体工厂类中，就可以创建一组产品类了 接下来我就用一个实际例子来说明吧！ 1创建抽象工厂类，定义具体工厂的公共接口 package CXGCMS; public abstract class Factory{ public abstract AbstractProduct ShowFirst(); public abstract AbstractProduct ShowSecond(); } 2创建抽象产品类，定义抽象产品组类的公共接口 package CXGCMS; public abstract class

一、抽象工厂模式 在介绍抽象工厂模式，我们先简单回顾一下简单工厂模式与工厂方法模式。 1.工厂模式：针对一个系列的类,它们有很多的共同点，因此可以将他们称为一个系列的产品，也就是一个系列的类。因此使用一个工厂，用一个工厂创建函数去创建某个具体的类。 实现流程如下： 系列类—>工厂—>创建函数—>某个具体的类 2.工厂方法模式：针对一系列的类，使用一个抽象的工厂接口，之后为每个具体的类都编写一个工厂类，随后在每一个类中使用创建函数创建具体类。 实现流程如下： 系列类——>抽象工厂接口—>多个与系列对应的工厂类—>每个类的创建函数—>某一个具体的类 回顾这些我们可以看出，简单工厂模式是笼统的承包服务，不管有多少个类需要创建，全部都由一个工厂去完成；而工厂函数模式则是定制化服务，每一个工厂只能创建某一种特定的类，但是这些工厂统一遵循即抽象工厂接口的创建方法。 抽象工厂模式即 是 “分类之后的一对一服务”，我们有多个系列的类需要创建，让某一个工厂专门负责某一类对象的创建，另一个工厂负责另外一类的对象创建。简单来说，简单工厂模式是集中式生产；工厂方法模式是分散式生产；而抽象工厂模式则是对于同一系列的集中式生产，而对于不同系列的分散式生产（结合前两者的优点）。 二、抽象工厂模式的使用情景 当出现一系列的产品族，且这些类比较容易划分时，设计模式可以采用使用抽象工厂模式。原因如下

什么是工厂方法模式 　　 工厂方法模式（FACTORY METHOD）是一种常用的类创建型设计模式,此模式的核心精神是封装类中变化的部分，提取其中个性化善变的部分为独立类，通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。它的核心结构有四个角色，分别是抽象工厂；具体工厂；抽象产品；具体产品。工厂方法(Factory Method)模式定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。 　　工厂方法模式是简单工厂模式的衍生，解决了许多简单工厂模式的问题。首先完全实现‘开－闭 原则’，实现了可扩展。其次更复杂的层次结构，可以应用于产品结果复杂的场合。工厂方法模式对简单工厂模式进行了抽象。有一个抽象的Factory类（可以是抽象类和接口），这个类将不再负责具体的产品生产，而是只制定一些规范，具体的生产工作由其子类去完成。在这个模式中，工厂类和产品类往往可以依次对应。即一个抽象工厂对应一个抽象产品，一个具体工厂对应一个具体产品，这个具体的工厂就负责生产对应的产品。 工厂方法模式的特点 工厂方法模式优点 (1)在工厂方法模式中,工厂方法用来创建客户所需要的产品

一、模式的定义与特点 1. 抽象工厂模式 　　抽象工厂模式是工厂方法模式的进一步延伸，由于它提供了功能更为强大的工厂类并且具备较好的可扩展性，在软件开发中得以广泛应用，尤其是在一些框架和API类库的设计中，例如在Java语言的AWT（抽象窗口工具包）中就使用了抽象工厂模式，它使用抽象工厂模式来实现在不同的操作系统中应用程序呈现与所在操作系统一致的外观界面。抽象工厂模式也是在软件开发中最常用的设计模式之一。 　　抽象工厂（Abstract Factory）模式的定义：是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。 　　抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。 　　使用抽象工厂模式一般要满足以下条件： 　　（1）系统中有多个产品族，每个具体工厂创建同一族但属于不同等级结构的产品。 　　（2）系统一次只可能消费其中某一族产品，即同族的产品一起使用。 2.主要优点 　　抽象工厂模式的主要优点如下： 　　（1）抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易，所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。 　　

软件领域中的设计模式为开发人员提供了一种使用专家设计经验的有效途径。设计模式中运用了面向对象编程语言的重要特性：封装、继承、多态。 本文对工厂模式进行详细讲解。 一、设计模式的分类 总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 此外还有两种：并发型模式和线程池模式。 二、设计模式的总原则和六大原则 总原则： 开闭原则（Open Close Principle） 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。 六大原则 　　1、单一职责原则：不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。 　　2、里氏替换原则（Liskov Substitution Principle） 里氏代换原则中说，任何基类可以出现的地方

工厂模式应用非常之广，在 JDK 底层源码以及各大主流框架中随处可见，一般以 Factory 结尾命名的类，比如 Mybatis 中的 SqlSessionFactory ， Spring 中的 BeanFactory 等，都是工厂模式的典型代表。 一、简单工厂模式 1.1 概念 简单工厂模式又称为静态工厂模式，属于设计模式中的创建型模式。简单工厂模式通过对外提供一个静态方法来统一为类创建实例，目的是实现类与类之间解耦:客户端不需要知道这个对象是如何被穿创建出来的，只需要调用简单工厂模式的方法来统一创建就可以了，从而明确了各个类的职责。 1.2 示例 简单工厂模式，以生产汽车轮胎为例。 1.2.1 实体类 轮胎通用属性 public class Tire { /** * 通用属性 */ private String common; } 奔驰车轮胎 包含通用属性外还有自己的特有属性 public class TireForBenz extends Tire{ Tire tire; /** * 特有属性 */ private String benz; public TireForBenz() { this.benz = "得到 Benz 轮胎"; } @Override public String toString() { return "["+this.benz +"]"; } }

　　抽象的艺术才有生命力 高层与底层组件之间都应该依赖于抽象的组件。这一条深刻揭示了抽象的生命力，抽象的对象才是最有表达能力的对象，因为它通常是“无形”的，可以随时填充相关的细节。 　　英文缩写DIP（Dependence Inversion Principle）。 　　原始定义：High level modules should depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details www.szihome.net should depend upon abstractions. 　　翻译过来就三层含义： 　　高层模块不应该依赖低层模块，两者都应该依赖其抽象； 　　抽象不应该依赖细节； 　　细节应该依赖抽象。 抽象：即抽象类或接口，两者是不能够实例化的。 细节：即具体的实现类，实现接口或者继承抽象类所产生的类，两者可以通过关键字new直接被实例化。 现在我们来通过实例还原开篇问题的场景，以便更好的来理解。下面代码描述了一个简单的场景，Jim作为人有吃的方法，苹果有取得自己名字的方法，然后实现Jim去吃苹果。 　　 　　问题由来：类A直接依赖类B，假如要将类A改为依赖类C

工厂模式 是创建型模式之一，其主要功能都是帮助我们把对象的实例化部分分离出来， 降低系统中代码耦合度 ，增强了系统的 扩展性 ，并 将对象的创建过程延迟到子类进行 工厂模式 分类： 简单工厂模式（Simple Factory）：只有一个工厂，通过向工厂传参来选择工厂所要生产的产品 工厂方法模式（Factory Method）：允许多个工厂，但一个工厂只生产一种产品，通过不同的工厂类型来选择所要生产的产品 抽象工厂模式（Abstract Factory）：允许多个工厂，一个工厂允许生产多种产品，通过工厂实例的不同方法来选择所要生产的产品 博文 / Github源码： 工厂模式 - SouthBegonia's Blog 工厂模式 - SouthBegonia's Github 简单工厂模式 含义：只有一个工厂类，客户端向工厂传递所需产品名，工厂生产产品交予客户 实现过程： 理论性：创建 产品的抽象类 做为产品基类， 产品类 （派生类）继承该基类并实现各自方法。 工厂类 负责接收客户端传入的参数（产品名），根据参数选择对应产品类进行实例化，最终返回给客户端 比喻：客户去印刷厂印刷书籍，客户只需要告诉印刷厂其需求（书名、材质 ..），印刷厂根据该需求选择印刷对应的书籍，最终交予客户 优缺点： 优点： 客户端无须知道所创建的具体产品类的创建细节，只需 将产品名参数传递到工厂类

继数据结构与算法之美后，王争老师的专栏又开始更新了，这次是《设计模式之美》，希望学习之后会对自己有所提升。在此记录下自己的学习笔记，希望对自己或者看到的读者都有所裨益。 为什么每个程序员都要尽早地学习并掌握设计模式相关知识？ 1. 应对面试中的设计模式相关问题 学习设计模式和算法一样，最功利、最直接的目的，可能就是应对面试了。 不管你是前端工程师、后端工程师，还是全栈工程师，在求职面试中，设计模式问题是被问得频率比较高的一类问题。特别是一些像 BAT 、 TMD 这样的大公司，比较重视候选人的基本功，经常会拿算法、设计模式之类的问题来考察候选人。 2. 告别写被人吐槽的烂代码 我们经常说， Talk is cheap，show me the code 。实际上，代码能力是一个程序员最基础的能力，是基本功，是展示一个程序员基础素养的最直接的衡量标准。你写的代码，实际上就是你名片。 3. 提高复杂代码的设计和开发能力 大部分工程师比较熟悉的都是编程语言、工具、框架这些东西，因为每天的工作就是在框架里根据业务需求，填充代码。实际上，这样的工作并不需要你具备很强的代码设计能力，只要单纯地能理解业务，翻译成代码就可以了。 但是，有一天， leader 让开发一个跟业务无关的比较通用的功能模块，面对这样稍微复杂的代码设计和开发，就发现会有点力不从心，不知从何下手了。因为只是完成功能、代码能用

设计模式（Design Pattern）一般指的是面向对象的二十三种设计模式，模式的解释是在某些场景下，针对某类问题的某种通用的解决方案。所谓设计模式就是一套被反复使用、经过分类的、代码设计经验的总结。使用设计模式的目的无非是为了在构架系统时保持高可扩展，高内聚，低耦合的特性，清晰，灵活，稳定的框架。 为何要让系统保持如何使系统保持高可扩展，高内聚，低耦合的特性的呢？ 首先高扩展意味着系统在开发过程中和开发完成后的升级中都能简单易行，可以比较容易的适应需求的变化改进系统。 内聚和耦合是模块独立程度的两个定性衡量标准，模块的独立使得软件开发，测试和维护都较为容易。模块化的设计使得系统功能可以分割，接口可以简化，分配给开发组中不同的人实现不同的功能；模块化的设计能使得修改设计和程序的工作量比较小，系统发生错误传播范围被限制，需要扩充时能插入模块。 什么耦合和内聚： 耦合是一个软件结构内模块之间的互连程度的度量，模块间的耦合程度强烈影响系统的可理解性，可测试性，可靠性和可维护性。耦合度从高到低： 内容耦合（content coupling） ：直接使用另一模块的内部数据/通过非正常入口进入模块内部。（一个模块可以通过非正常入口访问另一个模块内部，一个模块可以访问另一个模块的内部数据，两个模块一部分代码重叠，一个模块有多个入口） 公共耦合（common coupling ）