适合于初学者的关于Java的设计模式教程.zip

# 工厂模式(factory Design pattern)  电子产品在这个时代早就非常普遍了，大家的手机，平板，电脑等在持续的更新换代，各种品牌的手机也是层出不穷，每种品牌的电子产品在问世之前，都需要经过工厂将其生产出来。 像富士康这种代工厂几乎可以为任何品牌的任何电子产品代工，任何品牌的电子产品，只要设计出来，剩下的就交给工厂去生成，这就完事了。 这种模式在我们软件设计中属于典型的： ***工厂模式***, 工厂模式可以分为三种：**简单工厂模式(静态工厂方法)**， **工厂模式**， **抽象工厂模式**。今天我们就来逐个学习它。 ## 简单工厂模式(Simple factory design pattern) **简单工厂模式属于创建型设计模式， 定义一个工厂类，根据传入的参数不同返回不同的实例，被创建的实例具有共同的父类或接口。** 严格上来说，简单工厂模式其实并不算是一种设计模式，更多的时候是一种编程习惯。之所以称之为简单工厂模式，就是因为其足够简单。这种模式所做的工作就是使用一个工厂类，将产品生产出来即可。 最大的优势就是将生产对象的职责和对象本身进行了解耦，工厂负责了产品的创建过程，客户端不需要关注产品的具体创建过程。 ### 模式结构  主要角色如下： * **Factory**：即工厂类， 简单工厂模式的核心部分，负责实现创建所有产品的内部逻辑；工厂类可以被外界直接调用，创建所需对象 * **Product**：抽象类产品， 它是工厂类所创建的所有对象的父类，封装了各种产品对象的公有方法，它的引入将提高系统的灵活性，使得在工厂类中只需定义一个通用的工厂方法，因为所有创建的具体产品对象都是其子类对象 * **ConcreteProduct**：具体产品， 它是简单工厂模式的创建目标，所有被创建的对象都充当这个角色的某个具体类的实例。它要实现抽象产品中声明的抽象方法 ### 使用场景 其实由定义也大概能推测出其使用场景，首先由于只有一个工厂类，所以工厂类中创建的对象不能太多，否则工厂类的业务逻辑就太复杂了，其次由于工厂类封装了对象的创建过程，所以客户端应该不关心对象的创建。总结一下适用场景： 1. 需要创建的对象较少 2. 客户端不关心对象的创建过程。 由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。 当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利； 为了解决这些缺点，就有了工厂方法模式。 ## 工厂模式(Factory design pattern) ***工厂模式是一种创建型模式，定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。*** 工厂方法模式建议使用特殊的工厂方法代替对于对象构造函数的直接调用 （即使用 new运算符）。 不用担心， 对象仍将通过 new运算符创建， 只是该运算符改在工厂方法中调用罢了。 工厂方法返回的对象通常被称作 “产品” 通常情况下，我们会将工厂模式应用到下面的场景中： * 当一个类不知道它所必须创建的对象的类的时候。 * 当一个类希望由它的子类来指定它所创建的对象的时候。 * 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。 ### 模式结构  构成此模式的角色主要有以下几种： * **产品(Product)**: 将会对接口进行声明。 对于所有由创建者及其子类构建的对象， 这些接口都是通用的。 * **具体产品(Concrete Products)**: 是产品接口的不同实现。 * **创建者(Creator)**: 类声明返回产品对象的工厂方法。 该方法的返回对象类型必须与产品接口相匹配。你可以将工厂方法声明为抽象方法， 强制要求每个子类以不同方式实现该方法。 或者， 你也可以在基础工厂方法中返回默认产品类型。 * **具体创建者(Concrete Creators)**: 将会重写基础工厂方法， 使其返回不同类型的产品。 注意， 尽管它的名字是创建者， 但它最主要的职责并不是创建产品。 一般来说， 创建者类包含一些与产品相关的核心业务逻辑。 工厂方法将这些逻辑处理从具体产品类中分离出来。 打个比方， 大型软件开发公司拥有程序员培训部门。 但是， 这些公司的主要工作还是编写代码， 而非生产程序员。 注意， 并不一定每次调用工厂方法都会创建新的实例。 工厂方法也可以返回缓存、 对象池或其他来源的已有对象。 ### 模式的优缺点 #### 优点 1. 你可以避免创建者和具体产品之间的紧密耦合。 2. 单一职责原则。 你可以将产品创建代码放在程序的单一位置， 从而使得代码更容易维护。 3. 开闭原则。 无需更改现有客户端代码， 你就可以在程序中引入新的产品类型。 #### 缺点 1. 应用工厂方法模式需要引入许多新的子类， 代码可能会因此变得更复杂。 最好的情况是将该模式引入创建者类的现有层次结构中。 ### 总结 工厂方法模式通过引入工厂等级结构，解决了简单工厂模式中工厂类职责太重的问题，但由于工厂方法模式中的每个工厂只生产一类产品，可能会导致系统中存在大量的工厂类，势必会增加系统的开销。 此时，我们可以考虑将一些相关的产品组成一个“产品族”，由同一个工厂来统一生产，这就是**抽象工厂模式**的基本思想。 ## 抽象工厂模式(Abstract factory design pattern) ***抽象工厂模式是一种创建型设计模式， 它能创建一系列相关的对象， 而无需指定其具体类。*** 相比于工厂模式，你可以在这些场景中使用抽象工厂模式： * 如果代码需要与多个不同系列的相关产品交互， 但是由于无法提前获取相关信息， 或者出于对未来扩展性的考虑， 你不希望代码基于产品的具体类进行构建， 在这种情况下， 你可以使用抽象工厂。 抽象工厂为你提供了一个接口， 可用于创建每个系列产品的对象。 只要代码通过该接口创建对象， 那么你就不会生成与应用程序已生成的产品类型不一致的产品。 * 如果你有一个基于一组抽象方法的类， 且其主要功能因此变得不明确， 那么在这种情况下可以考虑使用抽象工厂模式。 在设计良好的程序中， 每个类仅负责一件事。 如果一个类与多种类型产品交互， 就可以考虑将工厂方法抽取到独立的工厂类或具备完整功能的抽象工厂类中。 ### 模式结构  此模式主要有以下几种角色构成： 1. **抽象产品(Abstract Product)**: 为构成系列产品的一组不同但相关的产品声明接口。 2. **具体产品(Concrete Product)**: 是抽象产品�