《JAVA与模式》之抽象工厂模式

合集下载

Java的23种开发模式

Java的23种开发模式

1、工厂模式:客户类和工厂类分开。

消费者任何时候需要某种产品,只需向工厂请求即可。

消费者无须修改就可以接纳新产品。

缺点是当产品修改时,工厂类也要做相应的修改。

如:如何创建及如何向客户端提供。

2、建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。

建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。

建造模式可以强制实行一种分步骤进行的建造过程。

3、工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。

4、原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。

原始模型模式允许动态的增加或减少产品类,产品类不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。

缺点是每一个类都必须配备一个克隆方法。

5、单例模式:单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模式。

单例模式只应在有真正的“单一实例”的需求时才可使用。

6、适配器(变压器)模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。

适配类可以根据参数返还一个合适的实例给客户端。

7、桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以独立的变化。

8、合成模式:合成模式将对象组织到树结构中,可以用来描述整体与部分的关系。

合成模式就是一个处理对象的树结构的模式。

合成模式把部分与整体的关系用树结构表示出来。

合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

java工厂类

java工厂类

Java工厂类Chapter 01工厂模式定义:提供创建对象的接口.为何使用?工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式,工厂模式在Java程序系统可以说是随处可见。

为什么工厂模式是如此常用?因为工厂模式就相当于创建实例对象的new,我们经常要根据类Class生成实例对象,如A a=new A() 工厂模式也是用来创建实例对象的,所以以后new时就要多个心眼,是否可以考虑实用工厂模式,虽然这样做,可能多做一些工作,但会给你系统带来更大的可扩展性和尽量少的修改量。

我们以类Sample为例, 如果我们要创建Sample的实例对象:Sample sample=new Sample();可是,实际情况是,通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先,我们想到的是,可以使用Sample的构造函数,这样生成实例就写成:Sample sample=new Sample(参数);但是,如果创建sample实例时所做的初始化工作不是象赋值这样简单的事,可能or 是很长一段代码,如果也写入构造函数中,那你的代码很难看了(就需要Refact重整)。

为什么说代码很难看,初学者可能没有这种感觉,我们分析如下,初始化工作如果是很长一段代码,说明要做的工作很多,将很多工作装入一个方法中,相当于将很多鸡蛋放在一个篮子里,是很危险的,这也是有背于Java面向对象的原则,面向对象的封装(Encapsulation)和分派(Delegation)告诉我们,尽量将长的代码分派“切割”成每段,将每段再“封装”起来(减少段和段之间偶合联系性),这样,就会将风险分散,以后如果需要修改,只要更改每段,不会再发生牵一动百的事情。

在本例中,首先,我们需要将创建实例的工作与使用实例的工作分开, 也就是说,让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了,不能再用上面简单new Sample(参数)。

抽象工厂模式的优缺点和适用场景

抽象工厂模式的优缺点和适用场景

抽象⼯⼚模式的优缺点和适⽤场景
抽象⼯⼚模式的优点
抽象⼯⼚模式除了具有⼯⼚⽅法模式的优点外,最主要的优点就是可以在类的内部对产品族进⾏约束。

所谓的产品族,⼀般或多或少的都存在⼀定的关联,抽象⼯⼚模式就可以在类内部对产品族的关联关系进⾏定义和描述,⽽不必专门引⼊⼀个新的类来进⾏管理。

抽象⼯⼚模式的缺点
产品族的扩展将是⼀件⼗分费⼒的事情,假如产品族中需要增加⼀个新的产品,则⼏乎所有的⼯⼚类都需要进⾏修改。

所以使⽤抽象⼯⼚模式时,对产品等级结构的划分是⾮常重要的。

适⽤场景
当需要创建的对象是⼀系列相互关联或相互依赖的产品族时,便可以使⽤抽象⼯⼚模式。

说的更明⽩⼀点,就是⼀个继承体系中,如果存在着多个等级结构(即存在着多个抽象类),并且分属各个等级结构中的实现类之间存在着⼀定的关联或者约束,就可以使⽤抽象⼯⼚模式。

假如各个等级结构中的实现类之间不存在关联或约束,则使⽤多个独⽴的⼯⼚来对产品进⾏创建,则更合适⼀点。

总结
⽆论是简单⼯⼚模式,⼯⼚⽅法模式,还是抽象⼯⼚模式,他们都属于⼯⼚模式,在形式和特点上也是极为相似的,他们的最终⽬的都是为了解耦。

在使⽤时,我们不必去在意这个模式到底⼯⼚⽅法模式还是抽象⼯⼚模式,因为他们之间的演变常常是令⼈琢磨不透的。

经常你会发现,明明使⽤的⼯⼚⽅法模式,当新需求来临,稍加修改,加⼊了⼀个新⽅法后,由于类中的产品构成了不同等级结构中的产品族,它就变成抽象⼯⼚模式了;⽽对于抽象⼯⼚模式,当减少⼀个⽅法使的提供的产品不再构成产品族之后,它就演变成了⼯⼚⽅法模式。

所以,在使⽤⼯⼚模式时,只需要关⼼降低耦合度的⽬的是否达到了。

简单工厂模式、工厂模式和抽象工厂模式区别及优缺点

简单工厂模式、工厂模式和抽象工厂模式区别及优缺点

简单⼯⼚模式、⼯⼚模式和抽象⼯⼚模式区别及优缺点各位⼩伙伴好,今天给⼤家主要介绍⼀下简单⼯⼚模式、⼯⼚模式和抽象⼯⼚模式的区别及各⾃的优缺点。

(本⽂实现语⾔为Python3)【前⾔】众所周知今天所讲的内容是设计模式的⼀类;对于设计模式这个概念,我想⾸先请⼤家问问⾃⼰:1、什么是设计模式 2、我们为什么要了解并学习设计模式?从我上学的时候我相信⼤家跟我⼀样也接触过设计模式的课程,当时可能懵懵懂懂只是知其然,当时还会想明明可以直接写出来为什么要搞成这样的形式,我就算学会了它到底什么时候能⽤呢?⼀系列的问题...Emm算了到时候再想想(lazy)。

随着实践的不断增多,现在我想可以对这些问题有个初步的回答了: 1、在我看来,设计模式外在看是经过前⼈不断实践总结出的针对某些指定场景极其好⽤的⼀种代码结构设计模板;内在看其实是⼀种设计思想(即为什么他们会这么想,这样想较之其他⽅法有什么好处)。

当我们真正的理解设计思想的时候,就可能会在⾯对问题和场景时⾃然⽽然的灵活运⽤到多种设计模式,⽽不是单⼀的刻板结构。

2、在⼯程化的开发中,需求往往是会不断变化的,这也是让很多开发⼈员及其烦躁的地⽅,所以才会有开发与产品的亲密关系。

设计模式就是为了抵御外部需求变化产⽣的。

设计模式应符合开闭原则(类、模块和函数等应该对扩展开放,对修改关闭。

)⼀个好的设计在之后的开发中,包括发⽣重⼤需求变化的时候,往往代码只需要进⾏简单重构去进⾏适配,⽽不是通过打补丁的⽅式去堆砌,也很容易避免破窗效应,充分的发挥了灵活的扩展和适配,⼤⼤增强了维护性。

综上所述,我们了解并学习设计模式,可以使我们的代码变得更加健壮、结构清晰,可以从容、灵活的适配需求变更(可复⽤、可扩展、可维护、够灵活)【正⽂】⾸先,这三种模式解决的问题是实例化对象的问题;那么为什么不直接实例化⽽⽤这样的⼯⼚形式去实例化对象呢?因为【待实例化对象太多(⼦类多且变动、调⽤频繁)或者实例化对象的过程、准备⽐较复杂】,直接实例化意味着每次都⽤重复的去执⾏实例化这个操作,如果有很多待实例化的操作,那么就要重复执⾏很多次,更不要说万⼀在实例化之前还要执⾏⼀堆配置项的初始化。

面向对象23种设计模式

面向对象23种设计模式

面向对象23种设计模式面向对象23种设计模式在面向对象的编程中,设计模式是一种解决问题的通用方案。

设计模式可以帮助开发人员在开发过程中减少代码的冗余和复杂性,并提高代码的可维护性和可重用性。

本文将介绍23种面向对象的设计模式。

1. 工厂方法模式工厂方法模式是一种创建型设计模式,它定义了一个用于创建对象的接口,但是让子类决定实例化哪个类。

在工厂方法模式中,客户端不需要知道具体的创建逻辑,只需要知道工厂类中定义的接口即可。

2. 抽象工厂模式抽象工厂模式是一种创建型设计模式,它提供了一个接口,用于创建相关或依赖对象的家族,而不需要指定它们的具体类。

在抽象工厂模式中,客户端不需要知道具体的创建逻辑,只需要知道工厂类中定义的接口即可。

3. 单例模式单例模式是一种创建型设计模式,它保证一个类只有一个实例,并提供一个访问该实例的全局点。

4. 原型模式原型模式是一种创建型设计模式,它允许复制或克隆一个现有的对象,而不必知道其具体实现。

5. 建造者模式建造者模式是一种创建型设计模式,它允许逐步创建复杂的对象,而不必知道其内部实现细节。

6. 适配器模式适配器模式是一种结构型设计模式,它将一个或多个不兼容的类或接口转换为客户端所需的接口。

7. 桥接模式桥接模式是一种结构型设计模式,它将抽象部分与其实现部分分离开来,以便独立地进行修改。

8. 组合模式组合模式是一种结构型设计模式,它将一组对象作为单个对象处理,以便客户端可以以相同的方式处理单个对象和组合对象。

9. 装饰器模式装饰器模式是一种结构型设计模式,它允许向现有对象添加额外的功能,同时不改变其现有的结构。

10. 外观模式外观模式是一种结构型设计模式,它为一组复杂的子系统提供了一个统一的接口,以便于客户端使用。

11. 享元模式享元模式是一种结构型设计模式,它利用共享技术来最小化内存使用,以及提高应用程序的性能。

12. 代理模式代理模式是一种结构型设计模式,它提供了一个代理对象,使得客户端可以通过代理对象间接地访问实际对象。

工厂模式的实现方式

工厂模式的实现方式

工厂模式的实现方式
工厂模式有以下几种实现方式:
1. 简单工厂模式:由一个工厂类负责创建对象,根据传入的参数不同,工厂类可以创建不同的对象。

这种方式对于创建简单的对象较为适用,但是如果需要创建复杂的对象或者对象之间存在复杂的依赖关系,则不太适用。

2. 工厂方法模式:定义一个创建对象的工厂接口,由具体的工厂类来实现这个接口,每个具体工厂类负责创建一种具体的对象。

这种方式可以避免简单工厂模式中的一个类负责创建所有对象的问题,而且可以方便地扩展创建新的对象。

3. 抽象工厂模式:定义一个抽象工厂接口,具体的工厂类实现这个接口并负责创建一组相关的对象。

这种方式可以创建一组相关的对象,而不仅仅是单个对象。

这三种实现方式都可以用来创建对象,具体选择哪一种方式取决于具体的需求和设计。

java常用的设计模式及应用场景

java常用的设计模式及应用场景一、单例模式(Singleton)单例模式是一种对象创建型模式,它指的是设计一个类,使其只能生成一个实例。

它只提供一个类实例,保证只有一个实例存在。

有时候,只需要一个类的实例来控制整个系统,例如实现一个全局的缓存,或是建立一个共享的日志记录器,单例模式可以很好的实现这个目的。

应用场景:1、对于需要频繁创建和销毁的对象,可以考虑使用单例模式,以避免过多地重复创建和销毁造成系统开销。

2、对于某些资源比较宝贵的对象,例如数据库连接,则可以用单例模式进行封装,保证全局应用程序只有一个,从而避免重复创建,浪费资源。

二、工厂模式(Factory)工厂模式是一种类创建型模式,它把类的实例化推迟到子类来完成。

它用于隔离客户类和实例化对象,通过声明抽象类类来定义构造过程,将不同的定义转移到不同的子类中去,从而使用户不需要关心实例化过程。

1、在有大量不同对象需要创建和管理的情况下,可以利用工厂模式封装类的实例化和存储,将池中不同对象来进行统一管理。

2、在使用设计模式的情况下,复杂的类结构已经不适合用一个实例来创建,可以采用工厂模式实现多个类的实例化,让用户不用关心对象实例的创建过程。

抽象工厂模式是一种工厂模式的拓展,它把简单工厂模式的单一职责拆分为多个类,从而实现一个系列相关的或相互依赖的工厂,以满足比较复杂的对象创建需求。

1、在需要创建复杂对象,而复杂对象又由多个部件组成的情况下,例如计算机,单一工厂模式已经不能满足需求,那么可以通过抽象工厂模式来实现。

2、在需要产生大量不同类型的对象,或者存在一系列相互依赖的产品族,这种情况下可以使用抽象工厂模式,将工厂定义为不同维度组成的一个系列。

四、建造者模式(Builder)建造者模式是一种设计模式,它也叫构造子模式,通过使用建造者模式,客户端可以不必担心具体的生产过程,只需要给出具体的请求,由建造者来负责构造出请求的产品对象。

1、在有复杂的产品对象的时候,例如需要对多个部件进行拼装,以构造出复杂的对象,可以采用建造者模式将复杂的拼装过程进行封装,避免复杂的拼装过程变得混乱。

java 面向对象的常用设计模式

java 面向对象的常用设计模式java 面向对象的常用设计模式有:1、观察者模式观察者模式又称为发布-订阅模式,定义了对象之间一对多依赖关系,当目标对象(被观察者)的状态发生改变时,它的所有依赖者(观察者)都会收到通知。

2、抽象工厂模式抽象工厂模式主要用于创建相关对象的家族。

当一个产品族中需要被设计在一起工作时,通过抽象工厂模式,能够保证客户端始终只使用同一个产品族中的对象;并且通过隔离具体类的生成,使得客户端不需要明确指定具体生成类;所有的具体工厂都实现了抽象工厂中定义的公共接口,因此只需要改变具体工厂的实例,就可以在某种程度上改变整个软件系统的行为。

3、单例设计模式单例设计模式可以确保系统中某个类只有一个实例,该类自行实例化并向整个系统提供这个实例的公共访问点,除了该公共访问点,不能通过其他途径访问该实例。

4、策略模式将类中经常改变或者可能改变的部分提取为作为一个抽象策略接口类,然后在类中包含这个对象的实例,这样类实例在运行时就可以随意调用实现了这个接口的类的行为。

比如定义一系列的算法,把每一个算法封装起来,并且使它们可相互替换,使得算法可独立于使用它的客户而变化,这就是策略模式。

5、适配器模式适配器模式主要用于将一个类或者接口转化成客户端希望的格式,使得原本不兼容的类可以在一起工作,将目标类和适配者类解耦;同时也符合“开闭原则”,可以在不修改原代码的基础上增加新的适配器类;将具体的实现封装在适配者类中,对于客户端类来说是透明的,而且提高了适配者的复用性,但是缺点在于更换适配器的实现过程比较复杂。

6、命令模式命令模式的本质是将请求封装成对象,将发出命令与执行命令的责任分开,命令的发送者和接收者完全解耦,发送者只需知道如何发送命令,不需要关心命令是如何实现的,甚至是否执行成功都不需要理会。

命令模式的关键在于引入了抽象命令接口,发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。

软件设计模式(13种设计模式详解及举例)

软件设计模式学习??????小组2013-3-25????_SS目录观察者模式 (1)定义 (1)模式实例 (1)结构类图 (2)类图解释 (2)适用 (4)缺点 (4)解决缺点 (4)与其他模式比较 (4)注意 (5)简单工厂模式 (6)定义 (6)实例 (6)结构类图 (8)类图解释 (8)适用 (8)优点 (9)缺点 (9)解决缺点 (9)与其他模式比较 (9)特点 (9)工厂方法模式 (10)定义 (10)模式实例 (10)结构类图 (11)类图解释 (11)适用 (12)缺点 (13)解决缺点 (13)与其他模式比较 (13)注意 (13)抽象工厂模式 (14)定义 (14)模式实例 (14)结构类图 (15)类图解释 (15)适用 (15)缺点 (16)解决缺点 (16)与其他模式比较 (16)注意 (16)策略模式 (17)模式实例 (17)类图 (18)类图解释 (18)适用 (18)缺点 (19)解决缺点 (19)与其他模式比较 (19)解释器模式 (20)定义 (20)模式实例 (20)结构类图 (20)类图解释 (20)适用 (21)优缺点 (21)解决缺点 (21)与其他模式比较 (21)注意 (21)装饰者模式 (22)定义: (22)类图: (22)类图解释: (23)适用: (25)三原则: (25)缺点: (26)与其他模式比较: (26)注意: (26)优点: (26)单件模式 (27)定义 (27)模式实例 (27)类图 (28)类图解释 (28)适用 (28)三原则 (29)缺点 (29)解决缺点 (29)与其他模式比较 (29)注意 (29)优点 (30)访问者模式 (30)定义 (30)模式实例 (30)类图 (32)适用 (35)缺点 (36)与其他模式比较 (36)注意 (36)优点 (36)门面模式 (36)定义 (36)模式实例 (36)类图 (41)类图解释 (42)适用 (42)三原则 (42)优点 (42)缺点 (43)解决缺点 (43)与其他模式比较 (43)注意 (43)享元模式 (43)定义 (43)模式实例 (44)类图 (46)类图解释 (47)适用 (47)三原则 (47)优点 (47)缺点 (47)注意 (47)适配器模式 (48)定义 (48)模式实例 (48)类图 (48)类图解释 (48)适用 (49)优点 (49)缺点 (49)解决缺点 (49)与其他模式比较 (49)注意 (50)代理模式 (50)定义 (50)模式实例 (50)类图 (51)类图解释 (51)优点 (52)缺点 (52)与其他模式比较 (52)注意 (52)观察者模式定义这一模式中的关键对象是目标(subject)和观察者(observer)。

工厂模式简介和应用场景

⼯⼚模式简介和应⽤场景⼀、简介⼯⼚模式主要是为创建对象提供了接⼝。

⼯⼚模式按照《Java与模式》中的提法分为三类:1. 简单⼯⼚模式(Simple Factory)2. ⼯⼚⽅法模式(Factory Method)3. 抽象⼯⼚模式(Abstract Factory)⼆、简单⼯⼚模式我喜欢吃⾯条,抽象⼀个⾯条基类,(接⼝也可以),这是产品的抽象类。

public abstract class INoodles {/*** 描述每种⾯条啥样的*/public abstract void desc();}先来⼀份兰州拉⾯(具体的产品类):public class LzNoodles extends INoodles {@Overridepublic void desc() {System.out.println("兰州拉⾯上海的好贵家⾥才5 6块钱⼀碗");}}程序员加班必备也要吃泡⾯(具体的产品类):public class PaoNoodles extends INoodles {@Overridepublic void desc() {System.out.println("泡⾯好吃可不要贪杯");}}还有我最爱吃的家乡的⼲扣⾯(具体的产品类):public class GankouNoodles extends INoodles {@Overridepublic void desc() {System.out.println("还是家⾥的⼲扣⾯好吃 6块⼀碗");}}准备⼯作做完了,我们来到⼀家“简单⾯馆”(简单⼯⼚类),菜单如下:public class SimpleNoodlesFactory {public static final int TYPE_LZ = 1;//兰州拉⾯public static final int TYPE_PM = 2;//泡⾯public static final int TYPE_GK = 3;//⼲扣⾯public static INoodles createNoodles(int type) {switch (type) {case TYPE_LZ:return new LzNoodles();case TYPE_PM:return new PaoNoodles();case TYPE_GK:default:return new GankouNoodles();}}}简单⾯馆就提供三种⾯条(产品),你说你要啥,他就给你啥。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
观察上面结果就会看出问题。客户选择的是 Intel 的 CPU 针脚数为 755,而选择的主板是 AMD,主板上的 CPU 插孔是 938,根本无法组装,这就是没有维护配件之间的关系造成的。 该怎么解决这个问题呢?
引进抽象工厂模式
每一个模式都是针对一定问题的解决方案。抽象工厂模式与工厂方法模式的最大区别就 在于,工厂方法模式针对的是一个产品等级结构;而抽象工厂模式则需要面对多个产品等级 结构。
在学习抽象工厂具体实例之前,应该明白两个重要的概念:产品族和产品等级。 所谓产品族,是指位于不同产品等级结构中,功能相关联的产品组成的家族。比如 AMD 的主板、芯片组、CPU 组成一个家族,Intel 的主板、芯片组、CPU 组成一个家族。而这两 个家族都来自于三个产品等级:主板、芯片组、CPU。一个等级结构是由相同的结构的产 品组成,示意图如下:
源代码
CPU 接口与具体实现
public interface Cpu { public void calculate(); }
public class IntelCpu implements Cpu {
private int pins = 0; public IntelCpu(int pins){ this.pins = pins; } @Override public void calculate() { // TODO Auto-generated method stub System.out.println("Intel CPU 的针脚数:" + pins); }
可以看出,一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所 有对象。显然,这时候抽象工厂模式比简单工厂模式、工厂方法模式更有效率。对应于每一 个产品族都有一个具体工厂。而每一个具体工厂负责创建属于同一个产品族,但是分属于不 同等级结构的产品。
抽象工厂模式结构
抽象工厂模式是对象的创建模式,它是工厂方法模式的进一步推广。 假设一个子系统需要一些产品对象,而这些产品又属于一个以上的产品等级结构。那么 为了将消费这些产品对象的责任和创建这些产品对象的责任分割开来,可以引进抽象工厂模 式。这样的话,消费产品的一方不需要直接参与产品的创建工作,而只需要向一个公用的工 厂接口请求所需要的产品。 通过使用抽象工厂模式,可以处理具有相同(或者相似)等级结构中的多个产品族中的 产品对象的创建问题。如下图所示:
public class Client { public static void main(String[]args){ ComputerEngineer cf = new ComputerEngineer(); cf.makeComputer(1,1); } }
运行结果如下:
上面的实现,虽然通过简单工厂方法解决了:对于装机工程师,只知 CPU 和主板的接 口,而不知道具体实现的问题。但还有一个问题没有解决,那就是这些 CPU 对象和主板对 象其实是有关系的,需要相互匹配的。而上面的实现中,并没有维护这种关联关系,CPU 和主板是由客户任意选择,这是有问题的。比如在客户端调用 makeComputer 时,传入参 数为(1,2),运行结果如下:
//直接找相应的工厂获取 this.cpu = CpuFactory.createCpu(cpuType); this.mainboard = MainboardFactory.createMainboard(mainboard);
//测试配件是否好用 this.cpu.calculate(); this.mainboard.installCPU(); } }
前面示例中创建 CPU 的简单工厂和创建主板的简单工厂,都不再需要。 新加入的抽象工厂类和实现类:
public interface AbstractFactory {
public Cpu createCpu();
public Mainboard createMainboard(); }
public class IntelFactory implements AbstractFactory {
//1:首先准备好装机所需要的配件 prepareHardwares(cpuType, mainboard); //2:组装机器 //3:测试机器 //4:交付客户 } private void prepareHardwares(int cpuType , int mainboard){ //这里要去准备 CPU 和主板的具体实现,为了示例简单,这里只准备这两个 //可是,装机工程师并不知道如何去创建,怎么办呢?
@Override public Cpu createCpu() { // TODO Auto-generated method stub return new IntelCpu(755); }
@Override public Mainboard createMainboard() {
// TODO Auto-generated method stub return new IntelMainboard(755); }
由于这两个产品族的等级结构相同,因此使用同一个工厂族也可以处理这两个产品族的 创建问题,这就是抽象工厂模式。
根据产品角色的结构图,就不难给出工厂角色的结构设计图。
可以看出,每一个工厂角色都有两个工厂方法,分别负责创建分属不同产品等级结构的 产品对象。
源代码
前面示例实现的 CPU 接口和 CPU 实现对象,主板接口和主板实现对象,都不需要变 化。
对于装机工程师而言,他只知道组装一台电脑,需要相应的配件,但是具体使用什么样 的配件,还得由客户说了算。也就是说装机工程师只是负责组装,而客户负责选择装配所需 要的具体的配件。因此,当装机工程师为不同的客户组装电脑时,只需要根据客户的装机方 案,去获取相应的配件,然后组装即可。
使用简单工厂模式的解决方案
显然,每一个产品族中含有产品的数目,与产品等级结构的数目是相等的。产品的等级 结构与产品族将产品按照不同方向划分,形成一个二维的坐标系。横轴表示产品的等级结构, 纵轴表示产品族,上图共有两个产品族,分布于三个不同的产品等级结构中。只要指明一个 产品所处的产品族以及它所属的等级结构,就可以唯一的确定这个产品。
}
public class AmdFactory implements AbstractFactory {
@Override public Cpu createCpu() { // TODO Auto-generated method stub return new IntelCpu(938); }
《JAVA 与模式》之抽象工厂模式
场景问题
举个生活中常见的例子——组装电脑,我们在组装电脑的时候,通常需要选择一系列的 配件,比如 CPU、硬盘、内存、主板、电源、机箱等。为讨论使用简单点,只考虑选择 CPU 和主板的问题。
事实上,在选择 CPU 的时候,面临一系列的问题,比如品牌、型号、针脚数目、主频 等问题,只有把这些问题都确定下来,才能确定具体的 CPU。
}
public class AmdMainboard implements Mainboard {
private int cpuHoles = 0;
public AmdMainboard(int cpuHoles){ this.cpuHoles = cpuHoles; } @Override public void installCPU() {
装机工程师类与客户类运行结果如下:
public class ComputerEngineer {
private Cpu cpu = null;
private Mainboard mainboard = null; public void makeComputer(int cpuType , int mainboard){
考虑客户的功能,需要选择自己需要的 CPU 和主板,然后告诉装机工程师自己的选择, 接下来就等着装机工程师组装电脑了。
对装机工程师而言,只是知道 CPU 和主板的接口,而不知道具体实现,很明显可以用 上简单工厂模式或工厂方法模式。为了简单,这里选用简单工厂。客户告诉装机工程师自己 的选择,然后装机工程师会通过相应的工厂去获取相应的实例对象。
同样,在选择主板的时候,也有一系列问题,比如品牌、芯片组、集成芯片、总线频率 等问题,也只有这些都确定了,才能确定具体的主板。
选择不同的 CPU 和主板,是每个客户在组装电脑的时候,向装机公司提出的要求,也 就是我们每个人自己拟定的装机方案。
在最终确定这个装机方案之前,还需要整体考虑各个配件之间的兼容性。比如:CPU 和主板,如果使用 Intel 的 CPU 和 AMD 的主板是根本无法组装的。因为 Intel 的 CPU 针脚 数与 AMD 主板提供的 CPU 插口不兼容,就是说如果使用 Intel 的 CPU 根本就插不到 AMD 的主板中,所以装机方案是整体性的,里面选择的各个配件之间是有关联的。
上面所给出的三个不同的等级结构具有平行的结构。因此,如果采用工厂方法模式,就 势必要使用三个独立的工厂等级结构来对付这三个产品等级结构。由于这三个产品等级结构 的相似性,会导致三个平行的工厂等级结构。随着产品等级结构的数目的增加,工厂方法模 式所给出的工厂等级结构的数目也会随之增加。如下图:
那么,是否可以使用同一个工厂等级结构来对付这些相同或者极为相似的产品等级 结构呢?当然可以的,而且这就是抽象工厂模式的好处。同一个工厂等级结构负责三个不同 产品等级结构中的产品对象的创建。
}
public class AmdCpu implements Cpu {
private int pins = 0; public AmdCpu(int pins){ this.pins = pins; } @Override public void calculate() { // TODO Auto-generated method stub System.out.println("AMD CPU 的针脚数:" + pins); } }
相关文档
最新文档