抽象工厂模式

前言 　　前面介绍了单例模式及工厂模式相关知识及示例，今天主要介绍的是抽象工厂模式，上一篇我们讲了工厂模式。将创建对象的任务委托给子类，延迟创建。解决工厂中责任的划分。实现具体工厂与产品之间的一一对应。解决的是”单个对象”的问题。 　　华为工厂除了生产华为手机之外。肯定也会有原件配套的充电线和耳机。这时工厂对应的是一套产品该如何解决了呢？显然不再适合使用工厂模式了。今天将的抽象工厂模式将会比较好的解决此问题。抽象工厂模式解决的是”一系列对象”的问题、解决多套变化的问题。 抽象工厂模式介绍 一、 来由 　　在我们编程的过程中难免会出现”一系列相互依赖对象”的创建问题，往往会有由于需要的改变增加或减少对象的创建。为了面对解决这种”一系列的相互依赖的对象”的创建工作的紧密耦合性，出现了其解决方案——抽象工厂模式。 二、 意图 　　提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 三、 案例图 四、 与工厂模式区别 工厂模式： 1、解决 ” 单个对象 ” 的问题 2、工厂类与产品类一一对应关系 抽象工厂模式： 1、解决 ” 一系列对象 ” 的问题 2、工厂类与产品类是一对多的关系（一对应一系列想依赖的产品） 工厂模式讲的是一个华为手机工厂生产一个华为手机，要生产其他的产品需另加工厂。抽象工厂模式讲的是一个华为手机工厂可以生产一系列的华为手机产品（手机、耳机、充电器）。

目录 一、创建型模式 1. 单例模式 1.1请手写一个单例 1.2单例模式的优点和应用？ 1.3单例模式的缺点 2. 工厂类相关模式 2.1工厂模式、简单工厂模式、抽象工厂模式 2.2工厂模式的优点和应用 2.3工厂模式的不足 3、建造者模式 3.2建造者模式的优点和使用场景 3.3建造者模式的缺点 4、原型模式 4.1原型模式 4.2原型模式的优点和使用场景 4.3原型模式的缺点 二、结构类设计模式 1、适配器模式 1.1适配器模式 1.2适配器模式的优点和使用场景 2、桥接模式 2.1桥接模式 2.2桥梁模式的优点和应用场景 3、 装饰器模式 3.1对装饰器的理解 ，并写出一个计时器记录方法执行性能的装饰器？ 3.2装饰器模式的优点和应用场景 3.3装饰器模式的缺点 4、组合模式 4.1组合模式 4.2组合模式的优点和使用场景 4.3组合模式的缺点 5、门面模式 5.1门面模式 5.3门面模式的缺点 6、享元模式 6.1享元模式 6.2享元模式的优点和使用场景 6.3享元模式的缺点 7、代理模式 7.1代理模式 7.2代理模式的优点和使用场景 7.3代理模式的缺点 三、行为类设计模式 1、策略模式 1.1策略模式 1.2策略模式的优点和应用场景 1.3策略模式的缺点 2、责任链模式 2.1责任链模式 2.2责任链模式的优点和应用场景 2.3责任链模式的缺点 3、 命令模式 3

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。 常用应用场景： 工厂模式 ：IOC就是典型的工厂模式 代理模式 ：AOP就是代理实现的 Facade模式 ：shiro框架的核心 单例模式 Spring默认就是单例 不变模式 string 八大基本数据类型都是单例 Future 模式 异步调用。即请求时只拿到一个契约，约定以后可以获取这个东西 来源： https://www.cnblogs.com/duguangming/p/11407721.html

从Android再来认识23种设计模式 ReadyShow 关注 0.2 2018.01.06 23:18* 字数 3855 阅读 2584 评论 0 喜欢 20 概况来看本文章的内容 创建型：5个 单例模式 Builder 原型模式 工厂方法 抽象工厂 行为型： 11个 策略模式 状态模式 观察者模式 中介者模式 访问者模式 迭代器模式 模板方法 备忘录模式 命令模式 解释器模式 职责链模式 结构型：7个 组合模式 代理模式 装饰模式 外观模式 享元模式 桥接模式 适配器模式 关于面向对象 面向对象的六大原则 谈到设计模式，不得不说说面向对象的六大原则 1. 单一原则 单一原则通俗的讲就是一个类只表达一个概念、一个方法只做一件事情。将一组相关性很高的函数、数据封装到一个类中。换句话说，一个类应该有职责单一。 2. 开闭原则 开闭原则就是一个类对于扩展是开发的，但是对于修改是封闭的。这也是六大原则中最难的，通常开闭都是短暂的美好，但在业务升级与拓展的状态下，原理的开闭是无法满足。即使是这样，也要尽可能的扩展而不是修改。 3. 里氏替换原则 所有引用基类的地方必须能透明地使用其子类对象 。看着定义很是抽象，但是通俗的理解就是由子类实例化的父类引用，在使用这个引用时，感觉就像是使用了父类一样。一个简单的例子： public class T{ private class A{...}

当一个应用中使用了大量的对象，会造成内存开销大，对象的大部分状态和参数（内部状态）都是相同的时候，可以使用享元模式。使用享元模式可以使这些对象都共享相同的实例。降低存储开销，而对象之间的不同的状态参数(外部状态)则使用外部参数传入来实现。 单纯的享元模式涉及到的角色主要有三个。 抽象享元角色：给出一个抽象接口，以规定具体享元角色需要实现的方法。 具体享元角色：实现抽象享元角色的接口，如果有内蕴状态（具体变量）的话，必须负责为内蕴状态提供存储空间（对其进行保存或者将值赋给新生成一个变量）。 享元工厂：负责创建和管理享元角色。此工厂需保证享元对象可以被系统适当地共享。当一个客户端对象调用一个享元对象的时候，享元工厂角色会检查系统中是否已经有一个符合要求的享元对象。如果已经有了，享元工厂角色就应当提供这个已有的享元对象；如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。 可以发现享元模式是简单工厂模式的包装，只是使用场景不一样。 java总的String类型的变量就是享元模式的实现。 具体实现代码如下： 新建一个抽象享元角色抽象接口： package flyWeight; public interface FlyWeight { public void operate(String s); } 再建一个具体享元角色： package flyWeight;

姓名：赵汉青 学号：07770201 模式名称：抽象工厂模式 1．问题描述 生活场景 ：某家具厂为学校生产课桌和座椅，开始只生产木质的课桌和座椅，后来经学校要求，又开始为学校生产铁质的课桌和座椅。 设计目标 ：实现针对多种成套产品的生产，每套产品有多种不同等级结构的物品组成。 2．不假思索的思路 思路描述 ：通过简单工厂的模式来实现。即在生产木质课桌的工厂里加开生产铁质课桌的生产线；在生产木质椅子的工厂里加开生产铁质椅子的生产线。 类结构图 缺点 ：这样的设计，工厂类集中了所有的实例的创建逻辑，违反了单一职责原则，即每一个类都只负责一件具体的事情；同时，当产品不断增多时，可能会出现要求工厂类根据不同条件创建不同实例的需求，工厂类就无法满足需求，不利于后续的扩充和维护。而且，这种方式割裂了产品簇之间的关系，不能体现出木桌椅或铁桌椅之间的配套关系。 代码： abstract class Desk //虚拟的课桌类 { public abstract void produce(); } class WoodDesk : Desk //木课桌类，继承课桌类 { public override void produce() { Console.WriteLine("木桌子"); } } class IronDesk : Desk //铁课桌类，继承课桌类 { public override

1、抽象工厂模式 1.1、什么是抽象工厂模式 抽象工厂模式是对象的创建模式，是工厂模式的进一步推广。抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。“抽象工厂”就是抽象产品角色的工厂。抽象工厂模式面对的问题是多个产品等级结构的系统设计。这里的“多个产品等级结构”就是别人所说的产品族。 1.1.1、产品族 产品族是指位于不同产品等级结构中，功能相关联的产品组成的家族。每个产品族中含有产品的数目与产品等级结构的数目是相等的。 1.2、抽象工厂模式的结构 抽象工厂类（AbstractFactory）角色 ：担任这个角色的是工厂方法模式的核心。通常使用接口或者抽象类实现。所有的具体工厂需要实现这个接口或者继承抽象类。 具体工厂类（Concrete Creator）角色 ：在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑。 抽象产品（Product）角色 ：工厂方法模式所创建的对象的父类，或它们共同拥有的接口。 具体产品（Concrete Product）角色 ：抽象工厂模式所创建的任何产品对象都是某一个具体产品类的实例。这是客户端最终需要的东西。 客户端： /** * 客户端 */ public class Client { public static void main(String[] args) { Creator creator1 = new

昨天我们说到了简单工厂模式，今天我们来说说工厂模式，还有抽象工厂模式。 工厂模式，顾名思义，就是在简单工厂模式的基础上继续优化，前面的简单模式当数量多时要改的地方很多，而且比较分散，修改起来比较麻烦，那么我们可以继续封装下。 var BookShop=function(type,content){ if(type in BookShop.types){ return new BookShop.types[type](content); }else{ alert("未找到对象"+type); } } BookShop.types={ Book:function(content){ this.name="Book"; this.content=content; }, Newspaper:function(content){ this.name="Newspaper"; this.content=content; }, Magazine:function(content){ this.name="Magazine"; this.content=content; } }; var book=BookShop("Book","书"); var news=BookShop("Newspaper","报纸"); var mag=BookShop("Magazine","杂志"); console

9.1 女娲的失误 我们在上一章节讲了女娲造人的故事。人是造出来了，世界也热闹了，可是低头一看，都是清一色的类型，缺少关爱、仇恨、喜怒哀乐等情绪，人类的生命太平淡了，女娲一想，猛然一拍脑袋，哇K！忘记给人类定义性别了，那怎么办？抹掉重来，于是人类经过一次大洗礼，所有的人种都消灭掉了，世界又是空无一物，寂静而又寂寞。 由于女娲之前的准备工作花费了非常大的精力，比如准备黄土，准备八卦炉等，从头开始建立所有的事物也是不可能的，那就想在现有的条件下重新造人，尽可能旧物利用嘛。先说人种（Product产品类）应该怎么改造呢？怎么才能让人类有爱有恨呢？是神仙当然办法的了，定义互斥的性别，然后在每个个体中埋下一颗种子：异性相吸，成熟后就一定会去找个异性（这就是我们说的爱情原动力）。从设计角度来看，一个具体的对象通过两个坐标就可以确定：肤色和性别，如图9-1所示。 图9-1 肤色性别坐标图 产品类分析完毕了，生产的工厂类该（八卦炉）怎么改造呢？只有一个生产设备，要么生产出全都是男性，要么都是女性，那不行呀，这么大的翻天覆地的改造就是为了产生不同性别的人类。有办法了！把目前已经有的生产设备——八卦炉拆开，于是女娲就使用了“八卦拷贝术”，把原先的八卦炉一个变两个，并且略加修改，就成了女性八卦炉（只生产女性人种）和男性八卦炉（只生产男性人种），于是乎女娲就开始准备生产了，其类图如图9-2所示。 图9-2

原文链接: http://blog.csdn.net/zhangerqing 一、设计模式的分类 总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 总原则：开闭原则（Open Close Principle） 开闭原则就是说 对扩展开放，对修改关闭 。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。 1、单一职责原则 不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。 2、里氏替换原则（Liskov Substitution Principle） 里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互