工厂方法模式

前面分析了简单工厂模式和工厂方法模式，接着来看一下抽象工厂模式，他与工厂方法模式有一些相似的地方，也有不同的地方。 先来看一个不用工厂方法模式实现的订购披萨的代码： 对象依赖的问题：当你直接实例化一个对象时，就是在依赖他的具体类。接着上面的例子，如果在一个PizzaStore里面直接创建很多对象时，他们的依赖关系是这样的： 这里引出一个概念： 依赖倒置。 很清楚的代码里减少具体类的依赖是一件好事。依赖倒置的定义是：要依赖抽象，不要依赖实现。这个原则说说明了：不能让高层组建依赖底层组件，而且，不管是高层组件还是底层组件，他们都要依赖抽象。所谓的高层组件，是由其它底层组件定义其行为的类。例如。PizzaStore是个高层组件，因为他的行为是由比萨定义的：PizzaStore创建所有不同的比萨对象，准备、烘烤、切片、装盒；而披萨本身属于低层组件。 原则的应用 上图展示的问题在于，它依赖每个比萨类型，因为它是在自己的orderPizza方法中，实例化这些具体类型的。虽然我们已经创建了一个抽象，就是Pizza，但是我们仍然在代码中，实际的创建了具体的pizza，所以，这个抽象没有什么影响力。如何在OrderPizza方法中，将这些实例化对象的代码独立出来，我们都知道， 工厂方法 刚好能排上用场。所以，应用工厂方法之后。类图看起来就像这： 在应用了工厂方法模式之后（ 参考工厂方法模式 ）

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 工厂方法设计模式： 一个抽象的产品类，派生出多个不同的产品，一个抽象工厂类，派生出多个不同的抽象工厂，每个工厂对应一个抽象的产品类。 缺点：在我们想要增加一个新的产品的时候，我们需要新增 一个对应的工厂。 举个例子：例如一个运算类，有加法类继承它，减法类继承它，同时实现它的抽象方法（计算方法）， 这时候我们就需要有加法工厂，减法工厂来与运算类一一对应。 客户端如果需要减法功能，就从减法工厂中获取一个减法类的实例，然后调用其方法即可。 public abstract class operation { //产品抽象基类 public int number1; public int number2; public abstract Object operation(); } public class add extends operation { //加法类 @Override public Object operation() { return number1+number2; } } public abstract class factory { //基本工厂，返回产品基类 public abstract operation getOpFactory(); } public class AddFactory

DesignPattern 项目地址： youlookwhat/DesignPattern 简介： Java 设计模式归纳 (观察者、工厂、单例、策略、适配器、命令、装饰者、外观、模板方法、状态). 更多： 作者 提 Bug 标签： 参照 Hongyang 的 CSDN 博客所写。如有错误欢迎指正，如有侵权，请联系我删除。 Java 设计模式（观察者模式、工厂模式、单例模式、策略模式、命令模式、装饰者模式、外观模式、模板方法模式、状态模式） 设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。 设计模式分为三种类型，共 23 种： 创建型模式 ： 单例模式 、抽象工厂模式、建造者模式、 工厂模式 、原型模式。 结构型模式 ： 适配器模式 、桥接模式、 装饰模式 、组合模式、 外观模式 、享元模式、代理模式。 行为型模式 ： 模版方法模式 、 命令模式 、迭代器模式、 观察者模式 、中介者模式、备忘录模式、解释器模式、 状态模式 、 策略模式 、职责链模式(责任链模式)、访问者模式。 Blog Catalogue： 1. 设计模式 观察者模式(Observer Pattern) 以微信公众服务为例 2. 设计模式 工厂模式(Factory Pattern) 从卖肉夹馍说起 3. 设计模式 单例设计模式(Singleton

模式定义 工厂方法模式又称工厂模式，也叫虚拟构造器模式或者多态工厂模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。 工厂方法模式包含如下角色： 1.Product抽象产品 抽象产品是定义产品的接口，是工厂方法模式所创建对象的超类型，也就是产品对象的共同父类或接口。 2.ConcreteProduct具体产品 具体产品实现了抽象产品接口，某种类型的具体产品由专门的具体工厂创建，它们之间一一对应。 3.Factory抽象工厂 在抽象工厂类中，声明了工厂方法，用于返回一个产品，抽象工厂是工厂方法模式的核心，它与应用程序无关。任何在模式中创建对象的工厂类都必须实现该接口。 4.ConcreteFactory具体工厂 具体工厂是抽象工厂类的子类，实现了抽象工厂中定义的工厂方法，并由客户端调用，返回一个具体产品类的实例。在具体工厂类中包含于应用程序密切相关的逻辑，并且接受应用程序调用以创建产品对象。 模式适用环境 （1）一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。 （2

一直想写一篇介绍设计模式的文章，让读者可以很快看完，而且一看就懂，看懂就会用，同时不会将各个模式搞混。自认为本文还是写得不错的😂😂😂，花了不少心思来写这文章和做图，力求让读者真的能看着简单同时有所收获。 设计模式是对大家实际工作中写的各种代码进行高层次抽象的总结，其中最出名的当属 Gang of Four ( GoF ) 的分类了，他们将设计模式分类为 23 种经典的模式，根据用途我们又可以分为三大类，分别为创建型模式、结构型模式和行为型模式。 有一些重要的设计原则在开篇和大家分享下，这些原则将贯通全文： 面向接口编程，而不是面向实现。这个很重要，也是优雅的、可扩展的代码的第一步，这就不需要多说了吧。 职责单一原则。每个类都应该只有一个单一的功能，并且该功能应该由这个类完全封装起来。 对修改关闭，对扩展开放。对修改关闭是说，我们辛辛苦苦加班写出来的代码，该实现的功能和该修复的 bug 都完成了，别人可不能说改就改；对扩展开放就比较好理解了，也就是说在我们写好的代码基础上，很容易实现扩展。 创建型模式比较简单，但是会比较没有意思，结构型和行为型比较有意思。 创建型模式 创建型模式的作用就是创建对象，说到创建一个对象，最熟悉的就是 new 一个对象，然后 set 相关属性。但是，在很多场景下，我们需要给客户端提供更加友好的创建对象的方式，尤其是那种我们定义了类

转发请注明出处： http://blog.csdn.net/qq_28055429/article/details/51628921 One----简单工厂模式： 一，基本知识： (1)定义： 简单工厂模式是属于创建型模式，又叫做静态工厂方法(Static Factory Method)模式，但不属于23种GOF设计模式之一。 (2)理解： 简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例 。简单工厂模式是工厂模式家族中最简单实用的模 式，可以理解为是不同工厂模式的一个特殊实现。 二，实现方法和角色： （1）实现方式： 简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类(这些产品类继承自一个 父类或接口)的实例。 （2）角色和责任 ：如图： 工厂(Creator)角色 ：简单工厂模式的 核心 ，它负责实现创建所有实例的内部逻辑。 工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。 抽象产品(Product)角色： 简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 具体产品(Concrete Product)角色： 是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。 三，优缺点： （1）优点： 在于工厂类中包含了必要的逻辑，根据客户需要的条件动态实例化相关的类， 对客户端来说

在现实生活中社会分工越来越细，越来越专业化。各种产品有专门的工厂生产，彻底告别了自给自足的小农经济时代，这大大缩短了产品的生产周期，提高了生产效率。同样，在软件开发中能否做到软件对象的生产和使用相分离呢？能否在满足“开闭原则”的前提下，客户随意增删或改变对软件相关对象的使用呢？这就是本节要讨论的问题。 模式的定义与特点 工厂方法（FactoryMethod）模式的定义：定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。 我们把被创建的对象称为“产品”，把创建产品的对象称为“工厂”。如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”，它不属于 GoF 的 23 种经典 设计模式 ，它的缺点是增加新产品时会违背“开闭原则”。 本节介绍的“工厂方法模式”是对简单工厂模式的进一步抽象化，其好处是可以使系统在不修改原来代码的情况下引进新的产品，即满足开闭原则。 工厂方法模式的主要优点有： 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程； 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则； 其缺点是：每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。 模式的结构与实现

文章目录 一、简单工厂模式 1.概述 2.实现 二、工厂方法模式 1.简述 2.实现 三、抽象工厂模式 1.概述 2.实现 三、总结 1.工厂模式优点 2.工厂模式适用场景 3.三种模型的区别 一、简单工厂模式 1.概述 简单工厂模式也叫静态工厂模式，将所有的创建对象任务交给了一个工厂类来实现，要想使用对象，直接找工厂类即可。 以动物工厂类为例，可以将创建动物对象的任务全放在动物工厂类来实现，在动物工厂类中定义静态方法，根据传递不同的参数类创建不同的动物对象。 要素分析： 定义抽象类：动物具有共同的属性：吃，因此可以创建一个动物抽象类，定义“吃”的抽象方法 定义具体的操作类：动物有很多，以猫和狗为例，创建猫类和狗类，继承动物类，实现“吃”的抽象方法 定义简单工厂：根据传递不同的参数类创建不同的动物对象 测试类：调用工厂类创建对象 2.实现 1.定义抽象类 public abstract class Animal { public abstract void eat ( ) ; } 2.定义具体的操作类 public class Cat extends Animal { public void eat ( ) { System . out . println ( "猫吃鱼" ) ; } } public class Dog extends Animal { public void

工厂方法模式扩展（一） 这篇博客主要介绍工厂方法模式的两种扩展：简单工厂模式（静态工厂方法模式）和多工厂模式 1. 简单工厂模式 这个模式在我的另一篇博客也写到过： 点击查看 简单工厂模式，又叫静态工厂方法模式。它的类图如下： 简单工厂模式，没有抽象的工厂接口，将工厂方法设置为静态方法，直接通过类名调用。它的优点就是足够简单。 与普通的工厂方法模式相比，简单工厂模式的扩展性很差，每次增加一个产品，都需要修改工厂方法，不符合开闭原则。但是，对于长期稳定的工厂来说，使用简单工厂模式也是可以选择的 2. 多个工厂类 因为简单工厂类实现了一个抽象的工厂接口，所以，有多个工厂类实现这个接口是“理所当然的”。可以给每一个产品类都对应一个工厂。就像下面的例子： 每个产品对应一个工厂，非常符合单一职责原则。但这样做也是不推荐的，产品类和工厂类数目相同，维护时需要考虑两个对象之间的关系。 这样的多工厂方式可以用来进行扩展，例如，原来的工厂方法是这样的，现在又来了一个新的需求，需要“生产”三角形，（这个例子在源代码里改也非常简单，但是如果是一个很大的项目，大到很难理清关系，改动源代码是有风险的，所以可以使用符合开闭原则的方式进行扩展） public class ShapeFactory implements Factory { /** * 根据传入的Class类的对象，通过反射创建一个类的实例 */

工厂方法模式的扩展（二）：替代单例模式 & 产品对象重复使用 这篇博客介绍下工厂方法模式的另外两种扩展：代替单例模式以及产品对象重复使用。 这两种扩展体现了一种思想：经常使用或全局共享以及必要情况下，没必要销毁对象 1. 代替单例模式 与其说代替单例模式，到不如所是用工厂模式实现单例模式。 对应代码如下：注意，构造器被私有化，工厂方法使用反射创建对象时要注意进行设置 public class Singleton { private Singleton(){} public void method(){ ... } } public class SingletonFactory { private static Singleton singleton; static{ try{ Class c = Class.forName(Singleton.class.getName()); Constructor constructor = c.getDeclaredConstructor(); constructor.setAccessible(true); singleton = (Singleton)constructor.newInstance(); } catch (Exception e){ } } public static Singleton getInstance(){