抽象工厂模式

抽象工厂（AbstractFactory）模式的定义：是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。抽象工厂不满足开闭原则。 在实际需求中，一个工厂，不可能都只生产一种产品。还是以水果为例，苹果，香蕉是水果。但是中国香蕉和日本香蕉，中国苹果和日本苹果就不一样。这时候需要抽象出一个工厂，既可以生产香蕉，又可以生产苹果。 #include <QCoreApplication> #include <iostream> using namespace std; class AbstractApple{ public: virtual void ShowName()=0; }; class AbstractBanana{ public: virtual void ShowName()=0; }; class ChinaApple:public AbstractApple{ public: virtual void ShowName(){ cout<<"China Apple"<<endl; } }; class ChinaBanana:public AbstractBanana{ public: virtual void ShowName(){ cout<<"China Banana"<<endl; } };

一、定义 抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定一个具体的类。 二、优点 1.方便更换产品的类型，由于具体工厂类在一个应用只需要初始化的时候出现一次，使得改变一个应用的具体工厂变得非常容易，只需改变具体的工厂即可使用不同的产品配置。 2.让具体的创建实例过程与客户端分离。客户端通过抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离。 三、示例代码 利用抽象工厂模式操纵数据库。 //抽象工厂类，利用了简单工厂模式+反射+读取配置文件来改造 import org.dom4j.Attribute; import org.dom4j.Document; import org.dom4j.DocumentException; import org.dom4j.Element; import org.dom4j.io.SAXReader; public class DataAccess { private static String packageName = "com.pattern.abstractFactory."; private static String db = readDb(); public static String readDb() { /*解析器*/ SAXReader saxReader = new SAXReader();

一、描述 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。好比不同品牌下有各式各样的商品。 二、优劣势 优点：用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件 体系结构的优化。 缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象里加代码，又要在具体的里面加代码。 三、需求 生产鼠标，有2个品牌，惠普和戴尔，每个品牌都能成产鼠标和键盘。 四、使用其他设计模式 简单工厂: https://blog.csdn.net/dicunsi2939/article/details/103922023 工厂模式: https://blog.csdn.net/dicunsi2939/article/details/103923644 如果我们这边也使用工厂模式，那么就会出现惠普鼠标工厂、惠普键盘工厂，那么从名字来看就有点耦合了，都是惠普工厂，干嘛还分鼠标和键盘，所以我们引用抽象工厂。 五、使用设计模式 通过添加工厂类，生成产品的工作交给它来负责。 3个类， MouseBase.cs -鼠标基类 HpMouse.cs -惠普鼠标类 DellMouse.cs -戴尔鼠标类 KeyBoardBase.cs 键盘基类 Hp KeyBoard.cs -惠普键盘类 Dell KeyBoard.cs

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。 行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式是 GoF 设计模式 中最为庞大的一类，它包含以下 11 种模式。 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象

第6章：工厂模式 一、简单工厂模式 （一）看一个具体的需求 看一个披萨的项目：要便于披萨种类的扩展，要便于维护 披萨的种类很多(比如 GreekPizz、CheesePizz 等) 披萨的制作步骤有： prepare，bake, cut, box 完成披萨店订购功能。 （二）使用传统的方式来完成 思路分析(类图) 2) 看老师代码的演示 public abstract class Pizza{ protect String name; // 因为不同的 Pizza 准备方法不同，因此做成抽象方法 public abstract void perpard(); public void bake(){ // XXXXX } public void cut(){ // XXXXX } public void box(){ // XXXXX } } //------------------------------------------------------- // 然后具体的 Pizza 实体继承 Pizza public void CheessPizza extends Pizza(){ //实现 prepare 方法 } //------------------------------------------------------- public void GreekPizza

一、Cocoa设计模式 　　Cocoa环境的许多架构和机制都能够有效地使用设计模式：抽象设计可以解决特定环境中的重复问题。 本文描述了Cocoa中设计模式的主要实现，主要关注模型(Model) - 视图(View) - 控制器(Controller)和对象建模。 本章的主要目的是让您更深入地了解Cocoa的设计模式，并鼓励您在自己的软件项目中利用这些模式。 二、什么是设计模式？ 　　 　　设计模式是设计的模板，它可以在特定的上下文中解决一般的、重复出现的问题。它是一种抽象工具，在建筑、工程和软件开发等领域都很有用。下面的部分总结了设计模式是什么，解释了为什么它们对于面向对象设计很重要，并讨论了一个示例设计模式。 三、Cocoa如何改变设计模式 　　 　　可以在OS X和iOS版本中找到适用于Cocoa的设计模式。 基于模式的机制和体系结构在Cocoa框架和Objective-C 的 runtime 和语言中很常见。Cocoa经常把自己独特的旋律放在一个模式上，因为它的设计受语言能力或现有体系结构等因素的影响。 　　本节包含大多数设计模式的摘要，这些设计模式是在“ 设计模式：可重用面向对象软件的元素”中编目的。 每个部分不仅总结了模式，还讨论了Cocoa的实现。 只列出Cocoa实现的模式，以下各节中的模式描述都与特定的Cocoa上下文有关。Cocoa设计模式的实现有多种形式。

　　说明：这些资料仅仅是对设计模式的一些总结，没有设计模式的相关知识，很难看懂。即使看懂了这些，也仅说明理解了模式的基本思想。想要学好设计模式，还是建议好好看文后所列的参考书籍和推荐书籍。 　　这些总结有不少是根据自己的理解写成的，或许并不正确。如果您有不同的看法，请告知作者，谢谢！ 　　欢迎传阅，但是请勿随意修改或Copy。 设计模式简介 　　每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。 -- Christopher Alexander 　　设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中,特定场景下，类(抽象类之间,抽象类和派生类)之间或者相互通信的对象之间常见的组织关系。 　　对象是什么？ ----从概念层面讲，对象是某种拥有责任的抽象。 ----从规格层面讲，对象是一系列可以被其他对象使用的公共接口。 ----从语言实现层面来看，对象封装了代码和数据 从设计原则到设计模式 针对接口编程，而不是针对实现编程 ---- 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。 优先使用对象组合，而不是类继承 ---- 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类和父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低

　　Factory英文名叫工厂，所以中文翻译为工厂模式，在这个模式中，主要的角色有Product，Factory，concreteProduct和concreteFactory，其中product和factory都是抽象的接口，属于framework包，而concreteProduct和concreteFactory是实际的类，这里我们把实际的类放入idcard包中，下面举例说明： 　　用factory method模式制作身份证； 　　首先创建product接口 1 package frameWork; 2 3 public interface Product { 4 public abstract void use(); 5 } 　　再创建Factory抽象类，这样工厂与产品的抽象关系就建立好了 1 package frameWork; 2 3 public abstract class Factory { 4 protected abstract void registerProduct(Product product); 5 6 protected abstract Product createProduct(String owner); 7 8 public final Product create(String owner) { 9 Product p =

8.1 女娲造人的故事东汉《风俗通》 记录了一则神话故事： “开天辟地， 未有人民， 女娲搏黄土做人”， 讲述的内容就是大家非常熟悉的女娲造人的故事。 开天辟地之初， 大地上并没有生物， 只有苍茫大地， 纯粹而洁净的自然环境， 寂静而又寂寞， 于是女娲决定创造一个新物种（即人类） 来增加世界的繁荣， 怎么制造呢？别忘了女娲是神仙， 没有办不到的事情， 造人的过程是这样的： 首先， 女娲采集黄土捏成人的形状， 然后放到八卦炉中烧制， 最后放置到大地上生长， 工艺过程是没有错的， 但是意外随时都会发生：第一次烤泥人， 感觉应该熟了， 往大地上一放， 哇， 没烤熟！ 于是一个白人诞生了！（这也是缺乏经验的最好证明。 ）第二次烤泥人， 上一次没烤熟， 这次多烤一会儿， 放到世间一看， 嘿， 熟过头了， 于是黑人诞生了！第三次烤泥人， 一边烧制一边察看， 直到表皮微黄， 嘿， 刚刚好， 于是黄色人种出现了！这个造人过程是比较有意思的， 是不是可以通过软件开发来实现这个过程呢？ 古人云： “三人行， 必有我师焉”， 在面向对象的思维中， 万物皆对象， 是对象我们就可以通过软件设计来实现。 首先对造人过程进行分析， 该过程涉及三个对象： 女娲、 八卦炉、 三种不同肤色的人。 女娲可以使用场景类Client来表示， 八卦炉类似于一个工厂， 负责制造生产产品（即人类） ， 三种不同肤色的人，

开发过程中经常听到工厂这个词，其实根据个人经验，简单工厂用的是比较多的。工厂方法和抽象工厂是GoF23种设计模式中的一种，而我们常使用的简单工厂并不是一种设计模式，可以说是我们自己的一种俗称。 定义 简单工厂： 直接通过一个Factory类创建多个实体类的构造方式。 工厂方法： 一个抽象产品类，可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类只能创建一个具体产品类的实例。 抽象工厂：个抽象产品类，每个抽象产品类可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类可以创建多个具体产品类的实例。 工厂方法与抽象工厂区别：工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。 工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。 模板 简单工厂 工厂方法 AbstractProduct ： 抽象产品 （在工厂方法模式中只有一个AbstractProduct） ConcreteProductXXX : 具体的产品类 AbstractFactory: 抽象工厂类 ConcreteFactory: 具体工厂类（每个工厂只能创建一个具体产品） 抽象工厂 ProductX ： 产品接口（抽象工厂中可以有多个产品抽象类） ConcreteProductX : 具体产品 Creator: 抽象工厂类