工厂方法模式

一、设计模式的分类 总体来说设计模式分为三大类： （1）创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 （2）结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 （3）行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 1、开闭原则（Open Close Principle） 开闭原则就是说 对扩展开放，对修改关闭 。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。 2、里氏代换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为

创建类模式包括: 工厂方法模式 建造者模式 抽象工厂模式 单例模式 原型模式 创建类模式能够提供对象的创建和管理职责. 其中单例模式和原型模式非常容易理解, 单例模式是要保持在内存中只有一个对象,原型模式是要求通过复制的方式产生一个新的对象,这两个不容易混淆. 工厂方法模式VS建造者模式 工厂方法模式注重的是整体对象的创建方法,而建造者模式注重的是部件构建的过程,旨在通过一步一步的精确构造创建出一个复杂的对象. 工厂方法模式和建造者模式的区别: 意图不同. 在工厂方法模式中, 我们关注的是产品的整体,无需关心产品的各部分是如何创建出来的; 但是在建造者模式中,一个具体产品的产生是依赖各个部件的产生以及装配顺序,它关注的是"由零件一步一步地组装出产品对象". 简单地说, 工厂模式是一个对象创建的粗线条应用,建造者模式则是通过细线条勾勒出一个复杂对象,关注的是产品组成部分的创建过程. 产品的复杂度不同. 工厂方法模式创建的产品一般都是单一性质产品,而建造者模式创建的则是一个复合产品,它由各个部件复合而成,不见不同产品对象当然不同. 在具体应用中如何选择呢?这取决于我们在做系统设计时的意图, 如果需要详细关注一个产品不见的生产、安装步骤,则选择建造者 ,否则选择工厂方法模式 抽象工厂模式VS建造者模式 抽象工厂模式实现对产品家族的创建, 一个产品家族是这样一系列产品:

定义： 为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。 类型： 创建类模式 类图： 抽象工厂模式与工厂方法模式的区别 抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。 在抽象工厂模式中，有一个 产品族 的概念：所谓的产品族，是指 位于不同产品等级结构中功能相关联的产品组成的家族 。抽象工厂模式所提供的一系列产品就组成一个产品族；而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。 在上面的类图中，两厢车和三厢车称为两个不同的等级结构；而2.0排量车和2.4排量车则称为两个不同的产品族。再具体一点，2.0排量两厢车和2.4排量两厢车属于同一个等级结构，2.0排量三厢车和2.4排量三厢车属于另一个等级结构；而2.0排量两厢车和2.0排量三厢车属于同一个产品族，2.4排量两厢车和2.4排量三厢车属于另一个产品族。 明白了等级结构和产品族的概念，就理解工厂方法模式和抽象工厂模式的区别了

昨天在搜抽象工厂模式时，发现有好几篇博文讲的实现方式和我所认知的有出入，而且还看到某某教程讲的也是错误的还在搜索引擎排第一。 大家讲的简单工厂模式和工厂方法模式都是没问题的，关键到抽象工厂模式就不对了。 先从简单工厂模式和工厂方法模式复习一下，然后再看看错的是咋讲的。已经对抽象工厂模式烂熟于心的请忽略此文。 简单工厂模式： 有个一公共的产品接口，定义一些方法，各个具体的产品类都实现这个接口，然后有一个专门生产产品类实例的类被称作工厂类，专门为客户端生产产品实例，这个工厂的内部实现就是使用switch或ifelse进行逻辑判断实现的，根据客户端传递的参数不同，来决定什么时候创建什么样的具体产品，生产出不同的具体产品返回给客户端。这样，这个工厂类就集成了所有产品的创建逻辑，它变得无所不知，这也让它变成了核心。但这也成为了他的缺点，因为它将所有的逻辑集中放在一个类里，当产品接口有了新的产品实现类，工厂类需要增加代码，判断在什么时候创建该产品，就需要加入新的判断逻辑。 ShoesFactory工厂 public class ShoesFactory{ public static final String NIKE = "NIKE"; public static final String ADIDAS = "ADIDAS"; public static Shoes getShoes

转载:原地址http://www.cnblogs.com/zhangchenliang/p/3700820.html 简单工厂、工厂方法、抽象工厂、策略模式、策略与工厂的区别 结合简单示例和UML图，讲解工厂模式简单原理。 一、引子 话说十年前，有一个爆发户，他家有三辆汽车（Benz（奔驰）、Bmw（宝马）、Audi（奥迪）），还雇了司机为他开车。不过，爆发户坐车时总是这样：上Benz车后跟司机说“开奔驰车！”，坐上Bmw后他说“开宝马车！”，坐上 Audi后他说“开奥迪车！”。 你一定说：这人有病！直接说开车不就行了？！而当把这个爆发户的行为放到我们程序语言中来，我们发现C语言一直是通过这种方式来坐车的！ 幸运的是这种有病的现象在OO语言中可以避免了。下面以Java语言为基础来引入我们本文的主题：工厂模式！ 二、简介 工厂模式主要是为创建对象提供了接口。工厂模式按照《Java与模式》中的提法分为三类： 1. 简单工厂模式(Simple Factory) 2. 工厂方法模式(Factory Method) 3. 抽象工厂模式(Abstract Factory) 这三种模式从上到下逐步抽象，并且更具一般性。还有一种分类法，就是将简单工厂模式看为工厂方法模式的一种特例，两个归为一类。两者皆可，这本为使用《Java与模式》的分类方法。 在什么样的情况下我们应该记得使用工厂模式呢

工厂方法模式（Factory Method），是23种设计模式之一。DP中是这么定义工厂方法模式的： 工厂方法模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。 所谓工厂方法模式，其实也像我们现实生活中的工厂，也是用来生产东西的，只不过我们代码中的工厂是用来生产对象的，不要想歪，此对象非彼对象233。 我们在开发过程中，总是要编写许许多多的类，当我们需要一些类的实例化对象时，如果总是不管三七二十一在代码上直接去new的话，倒也不是说不行，只是会导致代码比较糟糕、不灵活。例如，有些通用的功能类或者需要隐藏得比较深的类（隐藏类是方便后期更换），你在你写的代码上去new它的对象，那么如果后期这个类更名了、移除了、功能增删了，那么你的写的代码就有可能会崩掉，需要重新去修改这些new对象的地方才能再次让你的代码正常运行。这就是一种耦合度高的体现，所以我们首先应该依赖的是一个抽象的接口或父类，而不是依赖具体的子类，这也是依赖倒转原则强调的，除此之外我们最好不要在一些容易发生变动的地方直接通过子类类名去new对象，不然的话依旧会出现这种情况。所以我们应该把子类对象的创建交给别人去完成，而这个 “别人” 就是工厂。 如果学过简单工厂模式，就应该知道，工厂的目的是为了帮我们解决创建对象实例的问题，并且工厂能够隐藏类名及对象创建的细节

抽象工厂模式（Abstract Factory），是23种设计模式之一。DP中是这么定义抽象工厂模式的： 抽象工厂模式（Abstract Factory），提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类。 在学习抽象工厂模式之前，最好熟悉简单工厂模式以及工厂方法模式，这样对理解抽象工厂模式会有一定帮助，而且抽象工厂也是基于工厂方法模式的。 至于工厂是用来干什么的，我这里也不过多介绍了，因为之前在工厂方法模式里已经说过了，如果对工厂的概念不是太清楚的话，可以参考我之前的文章： https://blog.51cto.com/zero01/2067822 在这里我们暂时先不谈论抽象工厂是什么，因为如果直接上来就去描述、解释什么是抽象工厂，以及如何使用抽象工厂模式来设计代码，这样是无法很好的明白抽象工厂模式的概念以及它所带来的好处或坏处的，只会让人下意识的只去记住实现代码，而不是设计模式的思想。讲解其他模式也是一样，如果一上来就是代码+理论一顿灌，只会让人看得亿脸懵逼或似懂非懂。这就好比给你一块披萨告诉你很好吃，以及这块披萨上用了哪些好食材，你只管吃就可以了，那么如果你没有吃过难吃的披萨，可能就会以为披萨就应该是这个味道的。 所以我们先从有些糟糕的代码入手，并且分析这些代码哪些地方有问题，然后再演进成使用设计模式去重构代码，这样就能有一个明显的对比