抽象工厂模式

一、工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。 工厂模式在《Java与模式》中分为三类： 1）简单工厂模式（Simple Factory）：不利于产生系列产品； 2）工厂方法模式（Factory Method）：又称为多形性工厂； 3）抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品； 这三种模式从上到下逐步抽象，并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。 二、简单工厂模式 简单工厂模式又称 静态工厂方法模式 。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。 在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 先来看看它的组成： 1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。 2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口

一、工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。 工厂模式在《Java与模式》中分为三类： 1）简单工厂模式（Simple Factory）：不利于产生系列产品； 2）工厂方法模式（Factory Method）：又称为多形性工厂； 3）抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品； 这三种模式从上到下逐步抽象，并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。 二、简单工厂模式 简单工厂模式又称 静态工厂方法模式 。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。 在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 先来看看它的组成： 1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。 2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口

首先明确什么是工厂模式： （1） 可以使代码结构清晰，有效地封装变化。在编程中，产品类的实例化有时候是比较复杂和多变的，通过工厂模式，将产品的实例化封装起来，使得调用者根本无需关心产品的实例化过程，只需依赖工厂即可得到自己想要的产品。 （2） 对调用者屏蔽具体的产品类。如果使用工厂模式，调用者只关心产品的接口就可以了，至于具体的实现，调用者根本无需关心。即使变更了具体的实现，对调用者来说没有任何影响。 （3） 降低耦合度。产品类的实例化通常来说是很复杂的，它需要依赖很多的类，而这些类对于调用者来说根本无需知道，如果使用了工厂方法，我们需要做的仅仅是实例化好产品类，然后交给调用者使用。对调用者来说，产品所依赖的类都是透明的。 而且，工厂模式可以分为简单工厂模式、工厂方法模式、抽象工厂模式。下面是对这三种工厂模式的对比和分析。 【简单工厂模式】 1.概念： 从设计模式的类型上来说，简单工厂模式 是属于创建型模式，又叫做静态工厂方法（StaticFactory Method）模式，但不属于23种GDF 设计模式之一。简单工厂 模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。简单的说， 简单工厂模式更多的使用了面向对象编程中的多态性，基类的引用可以指向派生类，并且调用派生的方法，即多态性。 2.如图所示

一、前言 我们先来看看传统的三层架构，如下图所示： 从上图中我们可以看到：在传统的三层架构中，层与层之间是相互依赖的，UI层依赖于BLL层，BLL层依赖于DAL层。分层的目的是为了实现“高内聚、低耦合”。传统的三层架构只有高内聚没有低耦合，层与层之间是一种强依赖的关系，这也是传统三层架构的一种缺点。这种自上而下的依赖关系会导致级联修改，如果低层发生变化，可能上面所有的层都需要去修改，而且这种传统的三层架构也很难实现团队的协同开发，因为上层功能取决于下层功能的实现，下面功能如果没有开发完成，则上层功能也无法进行。 传统的三层架构没有遵循依赖倒置原则（DIP）来设计，所以就会出现上面的问题。 二、依赖倒置 依赖倒置(DIP)：Dependence Inversion Principle的缩写，主要有两层含义： 高层次的模块不应该依赖低层次的模块，两者都应该依赖其抽象。 抽象不应该依赖于具体，具体应该依赖于抽象。 我们先来解释第一句话：高层模块不应该直接依赖低层模块的具体实现，而是应该依赖于低层模块的抽象，也就是说，模块之间的依赖是通过抽象发生的，实现类之间不应该发生直接的依赖关系，他们的依赖关系应该通过接口或者抽象类产生。 在来解释第二句话：接口或者抽象类不应该依赖于实现类。举个例子，假如我们要写BLL层的代码，直接就去实现了功能，等到开发完成以后发现没有使用依赖倒置原则

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。 抽象工厂示例： 假设我们需要两种产品，分别是鼠标和键盘，鼠标由鼠标厂生产，键盘由键盘厂生产。工厂为两个品牌提供代工，分别是戴尔和惠普。如下： 首先创建两个接口，分别是Mouse接口和Keyboard接口，表示鼠标和键盘两个类族。 package AbstractFactory; public interface Keyboard { public void print(); } package AbstractFactory; public interface Mouse { public void print(); } 然后创建产品类：产品为戴尔鼠标、戴尔键盘、惠普鼠标、惠普键盘 package AbstractFactory; public class HPKeyboard implements Keyboard { public void print(){ System.out.println("惠普键盘"); } } package AbstractFactory;

刚学 Java 语言时，就很难理解为什么要有接口这个概念，虽说是可以实现所谓的多继承，可一个只有方法名，没有方法体的东西，我实现它又有什么用呢？我从它那什么也得不到，除了一些方法名，我直接在具体类里加入这些方法不就行了吗？ 为什么一定要有抽象类这个概念？为什么就不能把这个父类写成一个具体的类，子类再继承它不就可以了吗？何必弄一个抽象类出来，还要弄一些没有方法体的抽象方法，弄得又象接口又象类的，让人捉摸不定。 当我开始学习java设计模式，真正走进面向对象设计的大门之后，我才发现，自己对面向对象设计的理解原来是那么的片面，那么的肤浅，根本就没有真 正理解面向对象思想的精髓，在某一种程度上还受着面向过程的影响，以为弄出了一个个类，就算是面向对象了，而其实还是被过程所驱使着。 面向对象思想，最关键的就是 抽象 。 一个软件设计的好坏，我想很大程度上取决于它的整体架构，而这个整体架构其实就是你对整个宏观商业业务的抽象框架，当代表业务逻辑的高层抽象层结构 合理时，你底层的具体实现需要考虑的就仅仅是一些算法和一些具体的业务实现了。当你需要再开发另一个相近的项目时，你以前的抽象层说不定还可以再次利用 呢，面对对象的设计，复用的重点其实应该是抽象层的复用，而不是具体某一个代码块的复用. 既然面向对象设计的重点在于抽象，那Java接口和Java抽象类就有它存在的必然性了。

今天来学习一下抽象工厂模式，在学习之前有两个非常重要的概念，产品等级，产品族。 产品等级就是说，一类产品，比如电视机属于一类产品，不管它是什么牌子的，他都属于电视，再比如冰箱，也属于一个产品等级。 产品族是说由不同产品等级组成的产品家族，比如海尔冰箱，海尔电视等等组成海尔产品族。再比如小米电视，手机，电脑等等组成小米产品族。 抽象工厂模式是要创造出一个产品族。 我们以一个画画的例子来解释其中的具体内容。简单起见，我要画一个红色矩形，绿色圆形。这时我要有两个产品等级，形状和颜色，然后这两个等级组成具体的产品族（抽象工厂）而红色矩形就为具体工厂。 接下来代码实现，先来定义两个产品等级，形状和颜色，分别有一个画和填充的方法 public interface Shape { void draw ( ) ; } public interface Color { void fill ( ) ; } 然后定义具体的产品，也就是具体的形状，颜色 // 矩形 public class Rectangle implements Shape { @Override public void draw ( ) { System . out . println ( "矩形" ) ; } } // 圆形 public class Circle implements Shape { @Override

一、抽象工厂模式简介（ Bref Introduction ） 抽象工厂模式（ Abstract Factory Pattern ），提供一个创建一系列相关或者相互依赖对象的接口，而无需制定他们的具体类。优点是：易于交换产品系列，由于具体工厂类在一个应该用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂类变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。抽象工厂的另一个优点是，它让具体的创建实例与客户端分离，客户端是通过他们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户的代码中。 二、解决的问题（ What To Solve ） 常用用于解决数据访问程序，也就是说程序通过使用抽象工厂模式后，可以灵活地在不同的数据库之间切换，而不需要费时费力地改变原有程序。 三、抽象工厂模式分析（ Analysis ） 1 、抽象工厂模式结构 IProductA 、 IProductA 接口： 两个产品接口，他们都有可能有两种不同的实现。 ProductA1 、 ProductA2 ， ProductB1 、 ProductB2 具体实现类： 对两个产品接口的具体分类的实现。 AbstractFactory 抽象类： 抽象工厂接口，它里面应该包含所有产品创建的抽象方法。 ConcreteFactory1 、 ConcreteFactory2 具体工厂类

最近在看《重构与模式》，里面提到工厂模式，后来查看了园子里相关文章，发现这篇很详细，故转载。转自： 最近在看《重构与模式》，里面提到工厂模式，后来查看了园子里相关文章，发现这篇很详细，故转载。转自： 一、 抽象工厂（Abstract Factory）模式 抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。 为了方便引进抽象工厂模式，引进一个新概念：产品族（Product Family）。所谓产品族，是指位于不同产品等级结构，功能相关联的产品组成的家族。如图： 图中一共有四个产品族，分布于三个不同的产品等级结构中。只要指明一个产品所处的产品族以及它所属的等级结构，就可以唯一的确定这个产品。 引进抽象工厂模式 所谓的抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。如果用图来描述的话，如下图： 二、 Abstract Factory模式的结构： 图中描述的东西用产品族描述如下： 抽象工厂（Abstract Factory）角色：担任这个角色的是工厂方法模式的核心，它是与应用系统商业逻辑无关的。 具体工厂（Concrete Factory）角色：这个角色直接在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑，而这个逻辑是与应用系统的商业逻辑紧密相关的。 抽象产品（Abstract Product）角色

设计模式是可复用面向对象软件的基础。它是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。项目中合理利用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一种模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛利用的原因。 给设计模式进行分类，可以分为以下三大类：创建型模式、结构型模式、行为型模式。 创建型模式抽象了实例化过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。一、它们都将关于该系统使用哪些具体的类的信息封装起来。二、它们隐藏了这些类的实例是如何被创建和放在一起的。整个系统关于这些对象所知方法的是由抽象类所定义的接口。 结构型模式描述如何将类或者对象结合在一起形成更大的结构，就像搭积木，可以通过简单几亩地组合形成复杂的、功能更更为强大的结构。结构型模式可以分为类结构型模式和对象结构型模式：类结构型模式关注累的组合，有多个类可以组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系。对象结构型模式关心雷雨对象的组合，通过关联关系使得在一个类中定义另一个类的实例对象，然后通过该对象调用其方法。根据“合成复用原则”