文档库 最新最全的文档下载
当前位置:文档库 › Java23种设计模式(总结)

Java23种设计模式(总结)

Java23种设计模式(总结)
Java23种设计模式(总结)

Java设计模式

目录

1. 设计模式 (2)

1.1 创建型模式 (3)

1.1.1 工厂方法 (3)

1.1.2 抽象工厂 (5)

1.1.3 建造者模式 (9)

1.1.4 单态模式 (12)

1.1.5 原型模式 (14)

1.2 结构型模式 (16)

1.2.1 适配器模式 (16)

1.2.2 桥接模式 (18)

1.2.3 组合模式 (21)

1.2.4 装饰模式 (25)

1.2.5 外观模式 (27)

1.2.6 享元模式 (31)

1.2.7 代理模式 (33)

1.3 行为型模式 (36)

1.3.1 责任链模式 (36)

1.3.2 命令模式 (39)

1.3.3 解释器模式 (42)

1.3.4 迭代器模式 (44)

1.3.5 中介者模式 (48)

1.3.6 备忘录模式 (51)

1.3.7 观察者模式 (53)

1.3.8 状态模式 (57)

1.3.9 策略模式 (60)

1.3.10 模板方法 (62)

1.3.11 访问者模式 (64)

1. 设计模式(超级详细)

内容简介

有感于设计模式在日常开发中的重要性,同时笔者也自觉对设计模式小有心得,故笔者*写二十三种设计模式的简单例子、

并整理二十三种设计模式的理论部分,综合汇总成这份Java设计模式(疯狂J*va 联盟版),希望对大家有所帮助。

本份帮助文档主要是为了向读者介绍二十三种设计模式,包括模式的描述,适用性,模*的组成部分,并附带有简单的例

子和类*,目的是为了让读*了解二十三种*计模式,并能方便的查阅各种设计模*的用法及注意点。

所附的例子非常简单,慢慢的引导读者从浅到深了解设计模式,并能从中享受设计的乐趣。

由于每个人对设计*式的理解都不尽一致,因此,可能本文档的例子*有不恰当的地方,还望各位读者指出不恰当的地方。

欢迎登录疯狂J*va联盟进行技术交流,疯狂Java联盟的论坛宗旨是:所有的技术发帖,均有回复。

疯狂Java联盟网址:https://www.wendangku.net/doc/102655386.html,

笔者简介

笔者曾师从李刚老师学习Java,现居广州。对Java软件开发、各种Java开源技术都非常感兴趣,曾参与开发、主持*发过大

量Java、Java EE项目,对Java、Java *E项目有一定认识*见解。欢迎大家与笔者就Java、Java EE相*方面进行技术交流。

笔者现为疯狂Jav*联盟的总版主(论坛ID:杨恩雄),也希望通过该平台与大家分享Java、Java EE技术、*得。

本人邮箱:yangenxiong@https://www.wendangku.net/doc/102655386.html,

声明

本文档编写、制作过程中得到了疯狂Java联盟、以及笔者学习工作过程大量朋友的支持,大家都抱着一个目的:为国内软件

软件开发事业作出绵薄贡献。

我们在此郑重宣布,本*档遵循Apache 2.0协议。在完整保留全部文本(包括本版权页),并且不违反Apache 2.0协议的前提

下,允许和鼓励任何人进行全文转载及推广,我们放弃除署名权外的一切权利。

1.1 创建型模式

AbstractFactory ( 抽象工厂)

FactoryMethod ( 工厂方法)

Singleton ( 单态模式)

Builder ( 建造者模式)

Protot*pe * 原型模式)

1.1.1 工厂方法

*义一个用于创建对象的接口,让子类决定实例化哪一个类。FactoryMethod 使一个类的实例*延迟到其子类。

适用性

1.当一个类不知道它所必须创建的对象的类的时候。

2.当一个类希望由它的子类来指定它所创建的对象的时候。

3.当*将创建对象的职责委托给多个帮助*类中的某一个,并且*希望将哪一个帮助子类是代理者这一信息局部化的时候。

参与者

1.Product

定义工厂方法所创建的对象的接口。

2.ConcreteProduct

实现Product接口。

3.Creator

声明工厂方法,该方法返回一个Product类型的对象*

Creator也可以定义一个工厂方法的缺省实现,它返回一个缺省的ConcreteProduct对象。

可以调用工厂方法以创建一个Product对象。

4.ConcreteCreator

重定义工厂方法以返回一个ConcreteProduct实例。

类图

例子

*roduct

public interface Work {

void doWork();

}

ConcreteProduct

public class StudentWork implements Work {

public void doWork() {

System.out.println("学生*作业!");

}

}

public class TeacherWork implements Work {

public void doWork() {

System.out.println("老师审批作业!");

}

}

Creator

public interface IWorkFactory {

Work get*ork();

}

Concre*eCreator

pu*lic class StudentWorkFactory implements IWorkFactory {

public Work getWork() {

*eturn new StudentWork();

}

}

public class TeacherWorkFactory implements IWorkFactory {

public Work getWork() {

return new TeacherWork();

}

}

Test

public class Test {

public static void m*in(Strin*[] args) {

IWorkFactory studentWorkFactory = new StudentWorkFactory();

studentWorkFactory.getWork().d*Work();

IWorkFactory teacherWorkFactory * new TeacherWorkFactory();

teacherWorkFactory.g*tWork().*oWork();

}

}

result

学生做作业!

老师审批作业!

1.1.2 抽象工厂

提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。

适用性

1.一个系统要独立于它的*品的创建、组合和表示时。

2.一个系统要由多个产品系列中的一个来配置时。

3.当你要强调一系列相关的产品对象的设计以便进行联合使用时*

4*当你提供一个产品类库,而只想显示它们*接口而不是实现时。

参与者

1.Ab*tractFactory

声明一个创建抽象产品对象的操作接口。

2.ConcreteFactory

实现创建具体产品对象的操作。

*.AbstractProduct

为一类产品对象声明一个接口。

4.ConcreteProdu*t

定义一个将被相应的具体工厂创建的产品*象。

实现*bstractProduct接口。

5.Client

仅使用由AbstractFactory和AbstractProduc*类声明的接口类图

例子

*bstractFactory

public interface IAn*malFactory {

ICat createCat();

IDog cre*teDog();

}

ConcreteFactory

p*blic class BlackAnimalFactory implem*nts IAnimalFactory {

public ICat createCat() {

retur* new BlackCat();

}

public IDog createDog() {

return new BlackDog();

}

}

public class WhiteAnimalFac*ory imp*ements IAnimalFactory {

public ICat createCat() {

return new WhiteCat();

}

public IDog cre*teDog() {

return new WhiteDog();

}

}

Abstrac*Product

public interface ICat {

void eat();

}

public interface IDog {

void eat();

}

Concrete*roduct

public class Black*at implements ICat {

public void eat() {

System.out.println("The bl*ck cat is eating!");

}

}

public class WhiteCat implements *Cat {

public void eat() {

Sy*tem.out.prin*ln("The w*ite cat is eating!*);

}

}

public class BlackDog implements IDog {

public void eat() {

System.out.println("The black dog is eating");

}

}

public class WhiteDog implements IDog {

public void eat() {

System.out.println("The white dog is eat*ng!");

}

}

Client

public static void main(String[] args) {

IAnimalFactory blackAnimalFa*tory = new BlackAnimalFactory(); ICat blackCat = blackAnimalFactory.createCat();

blackCat.eat();

IDog blackD*g = blackAnimalFactory.createDog();

blackDog.eat();

IAnimalFactory whiteAnimalF*ctory = new WhiteAnimalFactory(); ICat whiteCat = whiteAnimalFactory.createCat();

whiteCat.eat();

IDog *hiteDog = whiteAnimalFactory.createDog();

whiteDog.eat();

}

res*lt

The bla*k cat is eating!

Th* black dog is eatin*!

The white cat is eating!

The white dog is *ating!

1.1.3 建造者模式

将一个复杂对象的构*与它的表示分离,使*同样的构建过程可以创建不同的表示。

适用性

1.当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

*.当构造过程必须允*被构造的对象有不同*表示时。

参与者

1.Builder

为创建一个Product对象的各个部件指定抽象接口。

2.ConcreteBuilder

实现Buil*er的接口以构造和装配该产品的各个部件。

定义并明确它所创建的表示*

提供一个检索产品的接口。

3.Director

构造一个使用Builder接口的对象。

4.Product

表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程。

包含定义组成部件的类,包括将这些部件装配成最终产品的接口。

类图

例子

Buil*er

public interface PersonBuilder {

void buildHead();

v*id buildBody();

void buildFoot()*

Person buildPerson();

}

ConcreteBuilder

public class ManBuilder implements PersonB*ilder { Person person;

public ManBuilder() {

person = ne* Man();

}

publ*c void build*ody() {

perso*.setBody("建造男人的身体");

}

public void buildFoot() {

person.setFo*t("建造男人的脚");

}

public void buildHead() {

pers*n.setHead("建造*人的头");

}

*ublic Person buildPerson() {

retur* person;

}

}

Dir*ctor

public class PersonDirec*or {

public Person constructPerson(PersonBuilder pb) { pb.buildHead();

pb.buildBody();

pb.buildFoot();

return pb.buildPerson();

}

}

Product

public class Person {

private String head;

private String body;

private String foot;

public String getH*ad() {

return head;

}

public void setHead(String hea*) {

this.head = head;

}

public String getBody() {

return body;

}

public void setBody(String body) {

this.b*dy = body;

}

public String getFoot() {

return foot;

}

public void setFoot(String foot) {

t*is.foot = foot;

}

}

public class Man extends Person {

}

Test

publ*c class Test{

public static void main(String[] ar*s) {

PersonDirector pd = new PersonDirector();

Person person = pd.constructPerson(new ManBuilder());

System*out.println(person.getBody());

System.out.println(person.getFoot());

System.out.println(person.getHead());

}

}

result

建造男人*身体

建造男*的脚

建造男人的头

1.1.4 单态模式

保证一个类仅有一个实例,*提供一个访问它的全局访*点。

适用性

1.当类只能有一个*例而且客户可以从一个众所周知的访问点访问它时。

2.当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时。

参与者

Singleton

定义一个Instance操作,允许客户访问它的唯一实例。Instance是一个类操作。

可能负*创建它自己的唯一实例。

类图

例子

Singleton

public class Singleton {

private static Singleton sing;

private Singleton() {

}

public st*tic Singleton get*nstance() {

if (sing == null) {

sing = new Singleto*();

}

return sing;

}

}

Test

public class Test {

public static void *ain(*tring[] args) {

Singleton sing = Singleton.getInstance();

Singleton si*g2 = Singleton.getI*stance();

System.out.println(sing);

System.out.pr*ntln(sing2);

}

}

result

singleton.Singleton@1c78e57

singleton.Singleton@1c78e57

1.1.5 原型模式

用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。

适用性

1.当一个系统应该独立于它的产品创*、构成和表示时。

2.当要实例化的类是在运行时刻指定时,例如,通过动态装载。

3.为了避免创建一个与产品类层次平行的工厂*层次时。

4.当一个类的实例只能有几个不同状态组合中的一种时。

建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

参与者

1. Prototype

声明一个克隆自身的接口。

2. ConcretePrototype

实现一个克隆自身的操作。

3. Client

让一个原型克*自身从而创建一个新的对象。

类图

例子

Prototype

public class Prototype implements Cloneable {

private String name;

public void setName(String name) {

https://www.wendangku.net/doc/102655386.html, = name;

}

public String getName() {

return https://www.wendangku.net/doc/102655386.html,;

}

public Object clone(){

try {

return super.clone();

} catch (Exception e) {

e.printStackTrace();

return null;

}

}

}

ConcretePrototype

publ*c class ConcretePrototype extend* Prototype {

public ConcretePrototype(String name) {

setName(name);

}

}

Client

public clas* Test {

public static void main(String[] args) {

Prototype pro = new ConcretePrototy*e("prototype"); Prototype pro2 = (Prototype)pro.clone();

*ystem.out.println(pro.getName()*;

System.out.println(pro2.getName());

}

}

result

prototype

prototype

1.2 结构型模式

Adapter * 适配器模式*

Bridge ( 桥接模* )

Composite ( 组合模式)

Decorator ( 装*模式)

Facade ( 外观模式)

Flyweight ( 享元模式)

Proxy ( 代理模式)

1.2.1 适配器模式

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口*兼容而不能一起工作的那*类可以一起工作。

适用性

1.你想使*一个已经存在的类,而它的接口不符合你的需求。

2.你想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类(即那*接口

可能不一定兼容的类)协同工作。

*.(仅适用于对象Adapter)你想使用一些已经存在的子类,但是不可能对每一个都进行

子类化以匹配它们的接口。对象适配器可以适配它的父类接口。

参与者

1.Target

定义Client使用的与特定领域相关的接口。

2.Client

与符合Target接口的对象协同。

3.Adapt*e

定义一个已经存在的接口,这个接口需要适配。

4.Adapter

对Adaptee的接口与Target接口进行适配

类图

例子

Target

public interface Target {

void adapteeMethod();

void adapterMethod();

}

Adaptee

public class Adaptee {

public void adapteeMethod() {

Syste*.out.p*intln("Adaptee method!");

}

}

Adapt*r

public clas* Adapter implement* Target {

private Adap*ee adaptee;

public Adapter(Adaptee adaptee) {

this.adapte* = adaptee;

}

public void adapteeMethod() {

adaptee.adapteeMethod();

}

public void adapterMethod() {

*ystem.out.println("Adapter method!"); }

}

Client

public cla*s Test {

public stati* void main(String[] args) {

Target target = new Adapter(new Adaptee());

tar*et.adapteeMethod();

target.adapterM*thod();

}

}

result

Adaptee method!

Adapter method!

1.2.2 桥接模式

将抽象部分与它*实现部分分离,使它们都可以独立地变化。

适用性

1.你不希望在抽*和它的实现部分之间有一个固定的绑定关系。

例如这种情况可能是因为,在程序运行时刻实现部分应可以*选择或者切换。

2.类的抽象以及它的实现都应该可以通*生成子类的方法加以扩充。

这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合,并分别对它们进行扩充。

3.对一个抽象的实现部分的修改应对客户不产生影响,即客户的代码不必重新编译。

4.正如在意图一节的第一个类图中所示的那样,有许多类要生成。

这*一种类层次结构说明你必须将一个对象分解成两个部分。

5.*想在多个对象间共享实现(可能使用引用计数),但同时要求客户并不知*这一点。

参与者

1.Abstraction

定义抽象类的接口。

维护一个指向Implementor类型对象的指针。

2.RefinedAbstraction

扩充由Abstraction定义的接口。

3.Implementor

定义实现类的接口,该接口不一定要与Ab*traction的接口完全一致。

事实上这两个接口可以完全不同。

*般来讲,Implementor接口仅提供基本操作,而Abstraction则定义了基于这些基本操作的较高层次的操作。

4.ConcreteImplementor

*现Implementor接口并定义它的具体实现。

类图

例子

Abstr*ction

public abstract class Person {

private Clothing clothing;

pr*vate String type;

public Clothing getClothing() {

return clothing;

}

publi* void setClothing() {

this.clothing = *lothingFactory.getClothing();

}

public void setType(String type) {

t*is.type = type;

}

public String getType() {

return this.ty*e;

}

public abstract void dress();

}

RefinedAbstraction

public class Man extends *erson {

public Man() {

setType("男人");

}

public void dress() {

Clothing clothing = get*lothing();

clothing.personDressCloth(this);

}

}

public class Lady extends Person {

public Lady() {

setTyp*("女人");

}

public void dress() {

Cloth*ng clothing = getClothing();

c*othing.personDressCloth(this);

}

}

Implemento*

public abstract class Clothing {

public abstract void personDressC*oth(*erson person); }

ConcreteImplemento*

public class *ack*t extends Clothing {

软件设计师23种设计模式总结

创建型结构型行为型 类Factory Method Adapter In terpreter Template Method 对象 Abstract Factory Builder Prototype Si ngleto n Apapter(对象) Bridge Composite Decorator Fa?ade Flyweight Proxy Chain of Resp on sibility Comma nd Iterator Mediator Meme nto Observer State Strategy Visitor (抽象工厂) 提供一个创建一系列相关或互相依赖对象的接口,而无须制定它们具体的类。 图10-25抽象工厂模式结构图 Abstract Factory 抽象工厂 class Program { static void Main(string[] args) { AbstractFactory factory1 = new Con creteFactory1(); Clie nt c1 = new Clie nt(factory1); c1.Ru n(); AbstractFactory factory2 = new Con creteFactory2(); Clie nt c2 = new Clie nt(factory2); c2.Ru n(); Co nsole.Read(); abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB

最新java设计模式考试题资料

1、设计模式一般用来解决什么样的问题( a) A.同一问题的不同表相 B不同问题的同一表相 C.不同问题的不同表相 D.以上都不是 2、下列属于面向对象基本原则的是( c ) A.继承 B.封装 C.里氏代换 D都不是 3、Open-Close原则的含义是一个软件实体( a ) A.应当对扩展开放,对修改关闭. B.应当对修改开放,对扩展关闭 C.应当对继承开放,对修改关闭 D.以上都不对 4、当我们想创建一个具体的对象而又不希望指定具体的类时,可以使用( a )模式。 A.创建型 B.结构型 C行为型 D.以上都可以 5、要依赖于抽象,不要依赖于具体。即针对接口编程,不要针对实现编程,是( d )的表述 A.开-闭原则 B.接口隔离原则 C.里氏代换原则 D.依赖倒转原则 6、依据设计模式思想,程序开发中应优先使用的是( a )关系实现复用。 A, 委派 B.继承 C创建 D.以上都不对 复用方式:继承和组合聚合(组合委派) 7、设计模式的两大主题是( d ) A.系统的维护与开发 B 对象组合与类的继承 C.系统架构与系统开发 D.系统复用与系统扩展 8、单子模式中,两个基本要点( a b )和单子类自己提供单例 A .构造函数私有 B.唯一实例 C.静态工厂方法 D.以上都不对 9、下列模式中,属于行为模式的是( b ) A.工厂模式 B观察者 C适配器以上都是 10、“不要和陌生人说话” 是( d )原则的通俗表述 A.接口隔离 B.里氏代换 C.依赖倒转 D.迪米特:一个对象应对其他对象尽可能少的了解 11、构造者的的退化模式是通过合并( c )角色完成退化的。 A.抽象产品 B产品 C创建者 D使用者

23种设计模式趣味讲解

23种设计模式趣味讲解 对设计模式很有意思的诠释,呵呵,原作者不详。 创立型模式 1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,固然口味有所不同,但不管你带MM往麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类离开。花费者任何时候需要某种产品,只需向工厂恳求即可。花费者无须修正就可以接纳新产品。毛病是当产品修正时,工厂类也要做相应的修正。如:如何创立及如何向客户端供给。 2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同处所的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM 我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这必定比美军在伊拉克用的翻译机好卖) 建造模式:将产品的内部表象和产品的天生过程分割开来,从而使一个建造过程天生具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变更,客户不必知道产品内部组成的细节。建造模式可以强迫履行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM往麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。 工厂方法模式:核心工厂类不再负责所有产品的创立,而是将具体创立的工作交给子类往做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的串口,而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天,必定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。(100块钱一份,你要不要) 原始模型模式:通过给出一个原型对象来指明所要创立的对象的类型,然后用复制这个原型对象的方法创立出更多同类型的对象。原始模型模式容许动态的增加或减少产品类,产品类不需要非得有任何事先断定的等级结构,原始模型模式实用于任何的等级结构。毛病是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个美丽的老婆,她们的老公都是我,我就是我们家里的老公Sigleton,

Gof的23种设计模式

Gof的23种设计模式 从2005年初听说设计模式,到现在虽然已经8年多了,但GoF的23种模式依然盛行,当然GoF提出这些模式的 年代更加久远(1995年)。在工作的过程中,陆陆续续接触了GoF的大部分模式,我记得在2008年的时候就想总结一下设计模式(最近想做的两件事情),最后因为各种原 因也没有完成。最近这段时间正好是职业空档期,没什么事儿做,就把之前看过的设计模式翻出来整理了一下,于是就有了上面几篇文章。整理设计模式的过程,也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾,让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”,特别是S.O.L.I.D,我觉得在这里再说一次,也不算矫情。S:单一职责原则(Single Responsibility Principle, SRP),一个类只能有一个原因使其发生改变,即一个类只承担一个职责。 O:开放-封闭原则(Open-Close Principle, OCP),这里指我们的设计应该针对扩展开放,针对修改关闭,即尽量以扩展的方式来维护系统。 L:里氏替换原则(Liskov Subsititution Principle, LSP),它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响,这样可以保证我们使用“继承”并没有破坏父类。

I:接口隔离原则(Interface Segregation Principle, ISP),客户端不应该依赖于它不需要的接口,两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法,而不是大量没用的方法。 D:依赖倒置原则(Dependence Inversion Principle, DIP),高层模块不应该依赖于低层模块,两者应该都依赖于抽象;抽象不依赖于细节,而细节应该依赖于抽象。这里主要是提倡“面向接口”编程,而非“面向实现”编程。设计模式,从本质上讲,是针对过去某种经验的总结。每种设计模式,都是为了在特定条件下去解决特定问题,离开这些前提去讨论设计模式,是没有意义的。下面,我们快速回顾GoF的23种模式。工厂方法 意图:定义一个用户创建对象的接口,让子类去决定具体使用哪个类。 适用场合:1)类不知道它所要创建的对象的类信息;2)类希望由它的子类来创建对象。抽象工厂 意图:提供一个创建一系列相关或者相互依赖的对象的接口,而无须指定它的具体实现类。 适用场合:1)系统不依赖于产品是如何实现的细节;2)系统的产品族大于1,而在运行时刻只需要某一种产品族;3)属于同一个产品族的产品,必须绑在一起使用;4)所有的

软件设计模式(JAVA)习题答案

软件设计模式(Java版)习题 第1章软件设计模式基础 1.1 软件设计模式概述 1.2 UML中的类图 1.3 面向对象的设计原则 一、名词解释 1.一个软件实体应当对扩展开放,对修改关闭,即在不修改源代码的基础上扩展 一个系统的行为。 2.一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。 3.在软件中如果能够使用基类对象,那么一定能够使用其子类对象。 4.是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结, 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 二、单选择题 1.( A ) 2.( A ) 3. ( A ) 4. ( D ) 5. ( D ) 6.( A ) 7. ( D ) 8.( D ) 9.( D ) 10.( E ) 11.( C ) 12.( C ) 13. ( A ) 三、多选择题 1.( A、B、C、D ) 2. ( A、B ) 3.( A、D ) 4.( A、B、C、D ) 四、填空题 1.依赖倒转、迪米特法则、单一职责 2.模式名字、目的、问题、解决方案、效果、实例代码 3.超类、子类 4.开闭 5.用户 6.依赖倒转 7.组合/聚合 8.结构型、行为型 9.依赖倒转 10.开闭 11.需求收集是否正确、体系结构的构建是否合理、测试是否完全 12.人与人之间的交流 13.接口 14.名称、目的、解决方案 15.对象组合、类继承

16.对象组合 17.对象组合、类继承 18.抽象类的指针 五、简答题 1.答:设计模式按类型分为以下三类: 1)创建型设计模式:以灵活的方式创建对象集合,用于管理对象的创建。 2)结构型设计模式:将己有的代码集成到新的面向对象设计中,用于处理类或对象的组合。 3)行为型设计模式:用于描述对类或对象怎样交互和怎样分配职责。 2.答:设计模式的主要优点如下: 1)设计模式融合了众多专家的经验,并以一种标准的形式供广大开发人员所用,它提供了一套通用的设计词汇和一种通用的语言以方便开发人员之间沟通和交 流,使得设计方案更加通俗易懂。 2)设计模式使人们可以更加简单方便地复用成功的设计和体系结构,将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式使得重用成功的设计更加容易,并避免那些导致不可重用的设计方案。 3)设计模式使得设计方案更加灵活,且易于修改。 4)设计模式的使用将提高软件系统的开发效率和软件质量,且在一定程度上节约设计成本。 5)设计模式有助于初学者更深入地理解面向对象思想,一方面可以帮助初学者更加方便地阅读和学习现有类库与其他系统中的源代码,另一方面还可以提高软件的设计水平和代码质量。 3.答:设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效 果、实例代码和相关设计模式,其中的关键元素包括模式名称、问题、解决方案和效果。 4.答:正确使用设计模式具有以下优点: ⑴可以提高程序员的思维能力、编程能力和设计能力。 ⑵使程序设计更加标准化、代码编制更加工程化,使软件开发效率大大提高,从 而缩短软件的开发周期。 ⑶使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。 5.答:根据类与类之间的耦合度从弱到强排列,UML中的类图有以下几种关系:依赖关 系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等,它们是最强的。

23种设计模式的通俗理解

23种设计模式的通俗理解【转】 1、FACTORY 工厂方法 追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 2、BUILDER 抽象工厂 MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱 你”builder。(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD 建造者模式 请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE 原型模式 跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。(100块钱一份,你要不要)原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类,产品类不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 5、SINGLETON 单态模式 俺有6个漂亮的老婆,她们的老公都是我,我就是我们家里的老公Sigleton,她们只要说道“老公”,都是指的同一个人,那就是我(刚才做了个梦啦,哪有这么好的事) 单例模式:单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。[b:9ceca65206]结构型模式[/b:9ceca65206] 6、ADAPTER 适配器模式 在朋友聚会上碰到了一个美女Sarah,从香港来的,可我不会说粤语,她不会说普通话,只好求助于我的朋友kent了,他作为我和Sarah之间的Adapter,让我和Sarah可以相互交谈了(也不知道他会不会耍我) 适配器(变压器)模式:把一个类的接口变换成客户端所期待的另一种接口,

关于23种设计模式的有趣见解

创建型模式 1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM 去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖) 建造模式:将产品的部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的部表象的产品对象。建造模式使得产品部表象可以独立的变化,客户不必知道产品部组成的细节。建

造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。 工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。(100块钱一份,你要不要) 原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类,产品类不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

23种模式详解

总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类:并发型模式和线程池模式。用一个图片来整体描述一下: 二、设计模式的六大原则 1、开闭原则(Open Close Principle)

开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。 2、里氏代换原则(Liskov Substitution Principle) 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则(Dependence Inversion Principle) 这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。 4、接口隔离原则(Interface Segregation Principle) 这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。 5、迪米特法则(最少知道原则)(Demeter Principle) 为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。 6、合成复用原则(Composite Reuse Principle) 原则是尽量使用合成/聚合的方式,而不是使用继承。 三、Java的23中设计模式 从这一块开始,我们详细介绍Java中23种设计模式的概念,应用场景等情况,并结合他们的特点及设计模式的原则进行分析。 1、工厂方法模式(Factory Method) 工厂方法模式分为三种:

Java23种设计模式6大原则总结

设计模式概念:一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素:模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类:创建型、结构型、行为型。 创建型模式功能:1.统所使用的具体类的信息封装起来; 2.类的实例是如何被创建和组织的。 创建型模式作用:1.封装创建逻辑,不仅仅是new一个对象那么简单。 2.封装创建逻辑变化,客户代码尽量不修改,或尽量少修改。 常见的创建型模式:单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式:代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式:模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则:一个类应该只有一个职责。 优点:降低类的复杂性;提高类的可读性;提高代码的可维护性和复用性;降低因变更引起的风险。 里氏替换原则: 优点:代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性;提高代码的可重用性;提高代码的可扩展性;提高产品或项目的开放性。 缺点:1.继承是入侵式的。只要继承,就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法,使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时,必须考虑子类的修改,这种 修改可能造成大片的代码需要重构。 依赖倒置原则:高层模块不应该依赖低层模块,两者都依赖其抽象;抽象不依赖细节;细节应该依赖于抽象。 在Java中的表现:模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;接口或抽象类不依赖于是实现类; 实现类依赖于接口或抽象类。 接口隔离原则:1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色,不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类:一个是门户,只能有查询方法;一个是外部系统,有添加订单的方法;一个是管理后台,添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则: 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口,若修改的风险较大,则可采用适配器模式进行转化处理。 4.接口设计应因项目而异,因环境而异,不能照搬教条。 迪米特法则:(表述)只与你直接的朋友们通信;不要跟“陌生人”说话;每一个软件单位 对其他的单位都只有最少的了解,这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个:外观模式、中介者模式。 开闭原则:一个软件实体应当对扩展开放,对修改关闭。 重要性体现:提高复用性;提高维护性;提高灵活性;易于测试

23种设计模式_UML_类图及对应示例代码

23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///

/// MainApp startup class for Structural /// Abstract Factory Design Pattern. ///

class MainApp { ///

/// Entry point into console application. /// public static void Main() { // Abstract factory #1 AbstractFactory factory1 = new ConcreteFactory1(); Client client1 = new Client(factory1); client1.Run(); // Abstract factory #2 AbstractFactory factory2 = new ConcreteFactory2(); Client client2 = new Client(factory2); client2.Run(); // Wait for user input Console.Read(); } } // "AbstractFactory" abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB CreateProductB(); } // "ConcreteFactory1" class ConcreteFactory1 : AbstractFactory { public override AbstractProductA CreateProductA() { return new ProductA1(); } public override AbstractProductB CreateProductB() { return new ProductB1(); } }

《JAVA设计模式》期末考试复习

《J A V A设计模式》复习资料 一、单项选择题 1.设计模式起源于() A、机械设计 B、建筑工程设计 C、水利工程设计 D、工业电力化设计 2.“不要和陌生人说话”是()原则的通俗表述。 A、接口隔离 B、里氏替换 C、依赖倒置 D、迪米特3.目前常见的设计模式主要有()种。 A、23 B、21 C、32 D、28 4.以下关于单一职责原则的叙述不正确的是()。 A、单一职责原则的英文名称是SingleResponsibilityPrinciple. B、单一职责原则要求一个类只有一个职责 C、单一职责原则有利于对象的稳定,降低类的复杂性 D、单一职责原则提高了类之间的耦合性 5.以下关于依赖倒置原则的叙述不正确的是() A、依赖倒置原则的简称是DIP B、高层模块不依赖于低层模块,低层模块依赖于高层模块 C、依赖倒置原则中高层模块和低层模块都依赖于抽象 D、依赖倒置原则实现模块间的松耦合 6.下面关于单例模式说法错误的是() A、单例模式是指一个类只有一个实例 B、单例类从实现方式上分为懒汉式和饿汉式 C、单例类从功能上分为状态单例类和无状态单例类 D、可以通过继承的方式对单例类进行扩展得到功能更丰富的单例类7.下面关于工厂方法模式说法错误的是()。 A、工厂方法模式使一个类是实例化延迟到其子类中 B、工厂方法模式中具有抽象工厂、具体工厂、抽象产品和具体产品4个角色 C、工厂方法模式可以处理多个产品的多个等级结构 D、工厂方法模式可以屏蔽产品类 8.在以下情况不适合使用责任职责链模式() A、有多个对象可以处理请求,哪个对象处理该请求在运行时刻自动确定。 B、在需要用比较通用和复杂的对象指针代替简单的指针的时候。 C、你想在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。 D、一个请求需要一系列的处理工作。 9.当我们想创建一个具体的对象而又不希望指定具体的类时,可以使用()模式 A、结构型 B、创建型 C、行为型 D、以上都可以 10.以下用来描述适配器模式的是()

Java23种设计模式(总结)

Java设计模式

目录 1. 设计模式3 1.1 创建型模式4 1.1.1 工厂方法5 1.1.2 抽象工厂9 1.1.3 建造者模式14 1.1.4 单态模式20 1.1.5 原型模式22 1.2 结构型模式25 1.2.1 适配器模式26 1.2.2 桥接模式29 1.2.3 组合模式35 1.2.4 装饰模式40 1.2.5 外观模式45 1.2.6 享元模式50 1.2.7 代理模式55 1.3 行为型模式59 1.3.1 责任链模式59 1.3.2 命令模式64 1.3.3 解释器模式69 1.3.4 迭代器模式73

1.3.5 中介者模式79 1.3.6 备忘录模式83 1.3.7 观察者模式88 1.3.8 状态模式94 1.3.9 策略模式98 1.3.10 模板方法102 1.3.11 访问者模式106

1. 设计模式(超级详细) 内容简介 有感于设计模式在日常开发中的重要性,同时笔者也自觉对设计模式小有心得,故笔者*写二十三种设计模式的简单例子、 并整理二十三种设计模式的理论部分,综合汇总成这份Java设计模式(疯狂J*va联盟版),希望对大家有所帮助。 本份帮助文档主要是为了向读者介绍二十三种设计模式,包括模式的描述,适用性,模*的组成部分,并附带有简单的例 子和类*,目的是为了让读*了解二十三种*计模式,并能方便的查阅各种设计模*的用法及注意点。 所附的例子非常简单,慢慢的引导读者从浅到深了解设计模式,并能从中享受设计的乐趣。 由于每个人对设计*式的理解都不尽一致,因此,可能本文档的例子*有不恰当的地方,还望各位读者指出不恰当的地方。 欢迎登录疯狂J*va联盟进行技术交流,疯狂Java联盟的论坛宗旨是: 所有的技术发帖,均有回复。 疯狂Java联盟网址: 笔者简介

关于23种设计模式新解

关于23种设计模式新解 创建型模式 1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你” builder。(这一定比美军在伊拉克用的翻译机好卖) 建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的

细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的 MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。 工厂方法模式:核心工厂类不再负责所有产品的创建,而是将 具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给 出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例 化这种细节。 4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里 面就行了,这就是我的情话prototype了。(100块钱一份,你要 不要) 原始模型模式:通过给出一个原型对象来指明所要创建的对象 的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类,产品类不需要非得有 任何事先确定的等级结构,原始模型模式适用于任何的等级结构。 缺点是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个漂亮的老婆,她们的老公都是我,

23种设计模式额形象比喻 (1)

1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM 爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory。工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM 到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好

设计模式课程设计

设计模式课程设计 题目:画图程序 学院:信息科学与技术学院 专业:软件工程 学号:20092384 姓名:陈志

1.需求分析 该系统是一个画图程序,我们要用设计模式的思想来设计系统结构,然后实现基本图形的绘制功能。 1.1 设计模式要求 至少在其中运用 6 种模式,其中涉及到的模式有装饰模式、策略模式、桥梁模式三种。 1.2 画图基本要求 能实现基本图形的绘制功能 1.3 画图高级要求 实现图形的操作(如选取、移动、放大、缩小、改变颜色、改变线形等)和持久化(利用文件或利用数据库)。 2.系统设计 首先,画图程序可以实现绘制圆形、矩形和按钮,这里可以将圆形、矩形和按钮看作三个不同的类,那么我们可以采用抽象工厂的方式来创建它们。对于画组合图,我们可以采用组合模式将二者结合起来。而对于图形颜色或者粗细的改变,我们可以使用外观模式。然后,我们可以使用原型模式来实现对于最后一个图形的复制。在系统中可以使用代理模式来实现显示图片。下面是对需要用到的设计模式进行的分析。 2.1 使用设计模式 2.1.1 桥梁模式 桥梁模式 , 结构型模式一种 .设计程序过程中 , 会经常使用到抽象类或者接口来完成抽象的过程。 继承或实现的类通过不同的实现方式来完成抽象类或接口的变化 , 也就是实现过程的变化 , 但可能会有这样的情况 , 抽象过程同样需要进行变化 , 也就是抽象类或者接口需要变化 , 这样就会造成原有的继承或实现关系复杂 , 关系混乱 .桥梁模式利用将抽象层和实现层进行解耦 , 使两者不再像继承或实现这样的较强的关系 , 从而使抽象和实现层更加独立的完成变化的过程 . 使系统更加清晰。 桥梁模式主要由抽象类、修正抽象类、实现类以及具体实现类组成 . 抽象类 , 制定接口 , 同时给出一个实现化的引用。 修正抽象类 , 扩展抽象类 , 修正或改变抽象类中指定的接口。 实现类 , 提供实现化角色的接口 , 但不进行具体实现过程 , 该接口不一定给出与抽象类相同的接口 , 只是提供实现的方式。 具体实现类 , 完成实现类中定义的实现接口的具体实现过程。 具体代码如下: package BridgePattern; import java.awt.Color;

23常用设计模式的UML

Factory模式 1.简单工厂模式,又称静态工厂模式 2.工厂方法模式 3. 抽象工厂模式 抽象工厂模式与工厂方法模式的最大区别在于,工厂方法模式针对的是一个产品等级结构;而抽象工厂模式则需要面对多个产品等级结构。

Singleton模式 要点: 类只能有一个实例 必须自行创建这个实例 必须自行向外界提供这个实例

Builder模式 Builder模式利用一个Director对象和ConcreteBuilder对象一个一个地建造出所有的零件,从而建造出完整的Product。Builder模式将产品的结构和产品的零件建造过程对客户端隐藏起来,把对建造过程进行指挥的责任和具体的建造者零件的责任分割开来,达到责任划分和封装的目的。 使用Builder模式的场合: 需要生成的产品对象有复杂的内部结构。每一个内部成分本身可以是对象,也可以紧紧是产品对象的一个组成部分。 需要生成的产品对象的属性相互以来。Builder模式可以强制实行一种分步骤进行的建造过程,因此,如果产品对象的一个属性必须在另一个属性被赋值之后才可以被赋值,使用建造模式便是一个很好的设计思想。 在对象创建过程中会使用到系统中的其他一些对象,这些对象在产品对象的创建过程中不易得到。

Prototype模式 通过给出一个原型对象来指明所要创建的对象的类型,然后用赋值这个原型对象的办法创建出更多同类型的对象。 Cloneable

Adapter模式 把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作,也就是说把接口不同而功能相同或相近的多个接口加以转换。 1.类的Adapter模式的结构 2.对象的Adapter模式的结构 注意两种结构的区别:主要就是Adaptee和Adapter的关系,一个为继承关系,一个为依

软件设计模式JAVA习题答案

软件设计模式(J a v a版)习题 第1章软件设计模式基础 1.1 软件设计模式概述 1.2 UML中的类图 1.3 面向对象的设计原则 一、名词解释 1.一个软件实体应当对扩展开放,对修改关闭,即在不修改源代码的基础上扩展 一个系统的行为。 2.一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。 3.在软件中如果能够使用基类对象,那么一定能够使用其子类对象。 4.是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结, 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 二、单选择题 1.( A ) 2.( A ) 3. ( A ) 4. ( D ) 5. ( D ) 6.( A ) 7. ( D ) 8.( D ) 9.( D ) 10.( E ) 11.( C ) 12.( C ) 13. ( A ) 三、多选择题 1.( A、B、C、D ) 2. ( A、B ) 3.( A、D ) 4.( A、B、C、D ) 四、填空题 1.依赖倒转、迪米特法则、单一职责 2.模式名字、目的、问题、解决方案、效果、实例代码 3.超类、子类 4.开闭 5.用户 6.依赖倒转 7.组合/聚合 8.结构型、行为型 9.依赖倒转 10.开闭

11.需求收集是否正确、体系结构的构建是否合理、测试是否完全 12.人与人之间的交流 13.接口 14.名称、目的、解决方案 15.对象组合、类继承 16.对象组合 17.对象组合、类继承 18.抽象类的指针 五、简答题 1.答:设计模式按类型分为以下三类: 1)创建型设计模式:以灵活的方式创建对象集合,用于管理对象的创建。 2)结构型设计模式:将己有的代码集成到新的面向对象设计中,用于处理类或对象的组合。 3)行为型设计模式:用于描述对类或对象怎样交互和怎样分配职责。 2.答:设计模式的主要优点如下: 1)设计模式融合了众多专家的经验,并以一种标准的形式供广大开发人员所用,它提供了一套通用的设计词汇和一种通用的语言以方便开发人员之间沟通和交 流,使得设计方案更加通俗易懂。 2)设计模式使人们可以更加简单方便地复用成功的设计和体系结构,将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式使得重用成功的设计更加容易,并避免那些导致不可重用的设计方案。 3)设计模式使得设计方案更加灵活,且易于修改。 4)设计模式的使用将提高软件系统的开发效率和软件质量,且在一定程度上节约设计成本。 5)设计模式有助于初学者更深入地理解面向对象思想,一方面可以帮助初学者更加方便地阅读和学习现有类库与其他系统中的源代码,另一方面还可以提高软件的设计水平和代码质量。 3.答:设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括模式名称、问题、解决方案和效果。 4.答:正确使用设计模式具有以下优点: ⑴可以提高程序员的思维能力、编程能力和设计能力。

23种设计模式

新版设计模式手册 一.创建型模式 1.单件模式 意图 保证一个类仅有一个实例,并提供一个访问它的全局访问点。 适用性 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。 当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时。 2.抽象工厂 意图 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。 适用性 一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个来配置时。 当你要强调一系列相关的产品对象的设计以便进行联合使用时。 当你提供一个产品类库,而只想显示它们的接口而不是实现时。 3.建造者模式 意图 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。 适用性 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。 当构造过程必须允许被构造的对象有不同的表示时。 4.工厂方法模式 意图 定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。 适用性 当一个类不知道它所必须创建的对象的类的时候。 当一个类希望由它的子类来指定它所创建的对象的时候。 当类将创建对象的职责委托给多个帮助子类中的某一个,并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。 5.原型模式

意图 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 适用性 当要实例化的类是在运行时刻指定时,例如,通过动态装载;或者 为了避免创建一个与产品类层次平行的工厂类层次时;或者 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。 二.结构型模式 6.适配器模式 意图 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 适用性 你想使用一个已经存在的类,而它的接口不符合你的需求。 你想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作。 (仅适用于对象Adapter)你想使用一些已经存在的子类,但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。 7.桥接模式 意图 将抽象部分与它的实现部分分离,使它们都可以独立地变化。 适用性 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为,在程序运行时刻实现部分应可以被选择或者切换。 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合,并分别对它们进行扩充。 对一个抽象的实现部分的修改应对客户不产生影响,即客户的代码不必重新编译。 有许多类要生成。这样一种类层次结构说明你必须将一个对象分解成两个部分。 你想在多个对象间共享实现(可能使用引用计数),但同时要求客户并不知道这一点。8.组合模式 意图 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite 使得用户对单个对象和组合对象的使用具有一致性。 适用性

相关文档
相关文档 最新文档