定义: 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. 工厂方法模式针对的是一个产品等级结构:而抽象工厂模式针对的是多个产品等级结构. 抽象工厂模式使用同一个 工厂等级结构负责这些不同产品等级结构产品对象的创建. 所谓的抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象. 注意: 如果不存在”多系列对象创建“的需求变化,则没必要应用Abstract Factory模式,静态工厂方法足矣. "系列对象"指的是这些对象之间有相互依赖.

1.定义 为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类. 2.适用场景 1.一个系统要独立于它的产品创建.组合和表示. 2.一个系统要由多个产品系列中的一个来配置. 3.当你要强调一系列相关的产品对象的设计以便进行联合使用. 4.当你提供一个产品类库,而只想显示它们的接口而不是实现. 3.评价 1.它分离了具体的类 2.它使得易于交换产品系列 3.它有利于产品的一致性 4.难以支持新种类的产品 5."开放-封闭"原则要求系统对扩展开放,对修改封闭.通过扩展达到增

1.模式定义: 抽象工厂是应对产品族概念的,提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们的具体类 2.模式特点: 抽象工厂模式为创建一组对象提供了一种解决方案.与工厂方法模式相比,抽象工厂模式中的具体工厂不只是创建一种产品,它负责创建一族产品: 3.使用场景: 为创建一组对象提供了一种解决方案: 4.模式实现: (1)抽象工厂角色:  这是工厂方法模式的核心,它与应用程序无关.是具体工厂角色必须实现的接口或者必须继承的父类.在java中它由抽象类或者接口来实现. //发动机以及型号

一.抽象工厂模式: 在工厂模式中具体的产品和具体的工厂是一一对应的,一个工厂只能生产一种产品,结构单一,例如小米公司刚开始是只生产小米手机,但是伴随着公司的发展,他们需要生产不同型号的手机,也会生产路由器,小米电视等等,那么工厂方法模式已不能满足业务的需求了,此时我们就需要抽象工厂模式,即一个工厂可以生产多种产品. 抽象产品:负责定义抽象工厂生成的产品的接口,在本例中有两个抽象产品类,分别是手机和电视的抽象类 电视(抽象类) watchTV 手机(抽象类) 打电话 public abstract

1.new 的问题 常见的对象创建方法: //创建一个Road对象 Road road=new Road(); new的问题:实现依赖,不能应对具体实例的变化 怎么理解上面这句话呢? 可以这样理解:我们创建的对象实例依赖于Road对象的内部实现,如果Road对象不会发生变化(或者发生变化的频率很小),那么单纯的用new是可以的,但是上面的Road我们单纯籽籽棉意思上理解,路肯定是变化很大的,路有水泥路,马路,公路等等,所以每当我们的Road发生变化,单纯用new的方式,我们就必须修改所有使用过R

简单工厂: 拿我们的简单三层举例子 先定义dal层 class Dal { public void Delete() { } } 工厂类 class Factory { //这样掉的好处是 当dal层发生变化的时候不需要去每个调用的地方修改对应的实例,只需要在工厂里面修改对应的实例就行. //例如Dal的名字换成DAL 这个时候只需要改动工厂里面对应的实例名称即可. public static Dal CreateInstance() { return new Dal(); } } 在BLL层中

问题: 使用工厂方法模式的主要问题是工厂类过多,每个产品对应一个工厂,不利于维护.因此可以考虑使用一个工厂创建一个产品族. 定义: 提供创建一些列相关或相互依赖的对象实例的接口,这些类可以称为一个产品家族. 结构图: AbstractProduct:抽象产品类,抽象工厂模式中至少含有一个抽象产品类,每个抽象产品类派生出一个产品结构,定义了该产品结构中所有派生类的公开方法,方便于该产品的扩展. ConcreteProduct:具体产品类,抽象工厂模式中含有多种具体产品类,实现其对应的抽象产品类定义

抽象工厂模式 理解了工厂方法模式,其实抽象工厂和工厂方法模式有很多的相似之处.抽象工厂同样是分离客户端对象的创建和逻辑代码的,但是抽象工厂往往是产生一组数据而不单单是产生一个产品. 抽象工厂提供一个创建一系列相关或相互依赖对象接口,而无需制定它们具体的类. 抽象工厂与工厂方法 抽象工厂 通过对象组合创建抽象产品 创建多系列产品 必须修改父类的接口才能支持新的产品 工厂方法 通过类继承创建抽象产品 创建一种产品 子泪花创建者并重载工厂方法以创建新产品 Demo 比较多就不一一的贴代码了,截类图 客

一.引言     写了3篇有关设计模式的文章了,大家有了些反馈,说能从中学到一些东西,我感到很欣慰,那就继续努力.今天我要写第四个模式了,该模式叫抽象工厂.上一篇文章我们讲了[工厂方法]模式,它是为了解决[简单工厂]模式所面对的问题,它的问题就是:如果我们增加新的产品,工厂类的方法就要修改本身的代码,增加产品越多,其逻辑越复杂,同时这样的修改也是不符合[开放关闭原则OCP],对修改代码关闭,对增加代码开放.为了解决[简单工厂]的问题,我们引出了[工厂方法]模式,通过子类化工厂类,解决了工厂类责任

一.引言 写了3篇有关设计模式的文章了,大家有了些反馈,说能从中学到一些东西,我感到很欣慰,那就继续努力.今天我要写第四个模式了,该模式叫抽象工厂.上一篇文章我们讲了[工厂方法]模式,它是为了解决[简单工厂]模式所面对的问题,它的问题就是:如果我们增加新的产品,工厂类的方法就要修改本身的代码,增加产品越多,其逻辑越复杂,同时这样的修改也是不符合[开放关闭原则OCP],对修改代码关闭,对增加代码开放.为了解决[简单工厂]的问题,我们引出了[工厂方法]模式,通过子类化工厂类,解决了工厂类责任的划分,

一:概念 抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的.抽象工厂模式可以向客户端提供一个接口,使得客户端在不必指定产品的具体类型的情况下,能够创建多个产品族的产品对象 二:动机 在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作:同时,由于需求的变化,往往存在更多系列对象的创建工作. 如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合. 三:和工厂方法模式区别 工厂模式只能生产一个产品 抽象工厂可以一次

抽象工厂模式(Abstract Factory) ——探索设计模式系列之三 Terrylee,2005年12月12日 概述 在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作:同时由于需求的变化,往往存在着更多系列对象的创建工作.如何应对这种变化?如何绕过常规的对象的创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?这就是我们要说的抽象工厂模式. 意图 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. 模型图 逻辑模型:

一.工厂模式(分为:简单工厂模式.工厂方法模式.抽象工厂模式) 实现了创建者和调用者的分离 核心本质:1.实例化对象,用工厂方法代替new操作:2.将选择实现类.创建对象统一管理和控制,从而将调用者跟实现类解耦. 简单工厂模式:用来生产同一等级结构中的任意产品(对于增加的新的产品,需要修改已有代码) 工厂方法模式:用来生产同一等级结构中的固定产品(支持增加任意产品) 抽象工厂模式:用来生产不同产品族中的全部产品(对于增加新的产品,无能为力.支持增加新的产品族) [扩展]面向对象设计的基本原则(核

注:关乎对象的创建方式的设计模式就是“创建型设计模式”(creational design pattern) 1.1 抽象工厂模式 “抽象工厂模式”(Abstract Factory Pattern)用来创建复杂的对象,这种对象由许多小对象组成,而这些小对象都属于某个特定的“系列”(family). 比如说,在GUI 系统里可以设计“抽象控件工厂”(abstract widget factory),并设计三个“具体子类工厂”(concrete subclass factory):MacWidge

(一)简单工厂模式? 现在的学习是面向对象面向接口的,但是执行时的操作需要实例化后的对象.随着我们需要的类的增加,我们就需要把这些共同的东西提取出来,放在一个抽象类中,让这些子类来继承抽象类.当我们调用具体的类时,需要首先实例化它们,而实例化必须要针对具体的类.如果直接实例化,则破坏了面向接口的原则,实例化一个具体的类就要根据父类把所有的子类选择一遍才可以实例化,这样的运算时间就大大增多.这时我们就需要有一个地方来供我们选择要实例化哪个类,而不需要我们知道怎么创建和调用类的,这就是简单工厂模式(

一.概述 抽象工厂模式是指当有多个抽象角色时,使用的一种工厂模式.抽象工厂模式可以向客户端提供一个接口,使客户端在不必指定产品的具体情况下,创建多个产品族中的产品对象. UML图: 其他的过多概念不再这里赘述,不如通过例子来实际感受与体会 二.实践 关键是搞清等级族的概念,这里以生产手机为例,假设生产小米5和小米6两个型号的手机,两个手机都有内存和处理器,但是内存和处理器的组合不同 :米5采用的是骁龙820+16G内存组合,而米6则是骁龙835+32G组合.生产对应产品的时候就会匹配对应的产品部

Abstract Factory 抽象工厂(创建型模式) 常见的对象创建方法:    //创建一个Road对象    Road road=new Road();    new的问题:    -实现依赖,不能应对“具体实例化类型”的变化    解决思路:    -封装变化点——那里变化,封装那里    -潜台词:如果没有变化,当然不需要额外的封装    工厂模式的缘起    变化点在“对象创建”,因此就封装“对象创建”    面向接口编程——依赖接口,而非依赖实现    最简单的解决方法:    

本文是自己学习所做笔记,欢迎转载,但请注明出处:http://blog.csdn.net/jesson20121020 工厂方法模式和抽象工厂模式不好区分清楚: 工厂方法模式特点: 1. 一个抽象产品类,能够派生出多个详细产品类. 2. 一个抽象工厂类,能够派生出多个详细工厂类. 3. 每一个详细工厂类仅仅能创建一个详细产品类的实例. 抽象工厂模式特点: 1. 多个抽象产品类,每一个抽象产品类能够派生出多个详细产品类. 2. 一个抽象工厂类.能够派生出多个详细工厂类. 3. 每一个详细工厂类能够

1.常规的对象创建方法(以更换QQ空间主题为例) (这里的常规对象指的是由于业务需求,当前实例化的对象有可能被其他相似的对象(有着共同的特性)所取代,例如更换手机铃声:一首歌取代另一首歌(词,曲,和声是他们的共同有的特性(这里说的词,曲,和声是当前实例化对象的属性,如果是对象的话,那我们就要使用抽象工厂了,第4会开始讲),只是词,曲的风格是不一样的!)) ModernTheme theme=new ModernTheme();//现代主题 常规的对象创建方法引发的问题是:当我们用户这时需要更换成

一.动机(Motivation) 在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作:同时,由于需求的变化,往往存在更多系列对象的创建工作. 如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合? 二.意图(Intent) 提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类. 三.结构(Structure) ProductA1和ProductB1是一个系列,ProductA2和