各个设计模式的优缺点

策略模式(Strategy Pattern)

设计原则

1、找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。

2、针对接口编程(实际上是针对超类编程),而不是针对实现编程。

3、多用组合,少用继承。


优点:1.利用组合、委托和多态等技术和思想,可以有效地避免多重条件选择语句

2、提供了对开放—封闭原则的完美支持,将算法封装在独立的strategy中,使得它们易于切换,易于理解,易于扩展

3、策略模式中的算法也可以复用在系统的其他地方,从而避免许多重复的复制粘贴工作。

4、在策略模式中利用组合和委托来让Context拥有执行算法的能力,这也是继承的一种更轻便的替代方案。

缺点:1.客户端必须知道所有的策略类,并自行决定使用哪一个策略类。

      2.造成很多的策略类。


详细请参考:http://www.cnblogs.com/mengdd/archive/2013/01/19/2867443.html


观察者模式

设计原则

1、为了交互对象之间的松耦合设计而努力。

优点:

1、当两个对象之间送耦合,他们依然可以交互,但是不太清楚彼此的细节。观察者模式提供了一种对象设计,让主题和观察者之间送耦合。主题所知道只是一个具体的观察者列表,每一个具体观察者都符合一个抽象观察者的接口。主题并不认识任何一个具体的观察者,它只知道他们都有一个共同的接口。

2、观察者模式支持“广播通信”。主题会向所有的观察者发出通知。

3、观察者模式符合“开闭原则”的要求。

缺点:

1、如果一个被观察者对象有很多的直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间。

2、如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进  行循环调用,可能导致系统崩溃。

3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的,而仅仅只是知道观察目标发生了变化。



详情请参考:http://blog.csdn.net/chenssy/article/details/8955696

http://www.cnblogs.com/mengdd/archive/2013/02/07/2908929.html

http://www.cnblogs.com/mengdd/archive/2013/02/08/2909206.html     


装饰器模式(Decorator)

设计原则

1、类应该对扩展开发,对修改关闭。

特点

1装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同的方式和装饰对象交互。

2装饰对象包含一个真实对象的引用(reference)。

3装饰对象接收所有来自客户端的请求,它把这些请求转发给真实的对象。

4、装饰对象可以在转发这些请求之前或之后附加一些功能。这样就确保了在运行时,不用修改给定对象的结构就可以在外部增加附加的功能

优点:动态的给一个对象添加一些额外的职责,就扩展功能而言,比生成子类方式更为灵活。

缺点:利用装饰器模式,常常造成设计中有大量的小类,数量实在太多,可能会造成使用此API程序员的困扰。例如:IO流

适用装饰者模式场合:
1.当我们需要为某个现有的对象,动态的增加一个新的功能或职责时,可以考虑使用装饰模式。
2.当某个对象的职责经常发生变化或者经搜索常需要动态的增加职责,避免为了适应这样的变化,而增加继承子类扩展的方式,因为这种方式会造成子类膨胀的速度过快,难以控制

动态的给一个对象添加一些额外的职责

,

就扩展功能而言比生成子类方式更为灵活

 


动态的给一个对象添加一些额外的职责

,

就扩展功能而言比生成子类方式更为灵活

 

动态的给一个对象添加一些额外的职责

,

就扩展功能而言比生成子类方式更为灵活

 

详情请参考:http://www.cnblogs.com/mengdd/archive/2013/02/12/2910302.html


简单工厂模式

简单工厂模式(Simple Factory Pattern)属于类的创新型模式,又叫静态工厂方法模式(Static FactoryMethod Pattern),是通过专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

优点:工厂类是整个模式的关键所在。它包含必要的判断逻辑,能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例,而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。

 缺点:由于工厂类集中了所有实例的创建逻辑,这就直接导致一旦这个工厂出了问题,所有的客户端都会受到牵连;而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口,这样一来,但产品的种类增加的时候,即有不同的产品接口或者抽象类的时候,工厂类就需要判断何时创建何种种类的产品,这就和创建何种种类产品的产品相互混淆在了一起,违背了单一职责,导致系统丧失灵活性和可维护性。而且更重要的是,简单工厂模式违背了“开放封闭原则”,就是违背了“系统对扩展开放,对修改关闭”的原则,因为当我新增加一个产品的时候必须修改工厂类,相应的工厂类就需要重新编译一遍。

总结一下:简单工厂模式分离产品的创建者和消费者,有利于软件系统结构的优化;但是由于一切逻辑都集中在一个工厂类中,导致了没有很高的内聚性,同时也违背了“开放封闭原则”。另外,简单工厂模式的方法一般都是静态的,而静态工厂方法是无法让子类继承的,因此,简单工厂模式无法形成基于基类的继承树结构。


详情请参考:http://blog.csdn.net/weiwenlongll/article/details/6918164

代码请参考:http://www.cnblogs.com/mengdd/archive/2013/01/04/2844868.html


工厂方法模式

工厂方法模式,英文Factory method pattern,工厂方法模式是简单工厂模式的进化版,工厂方法模式是定义一个创建产品对象的工厂接口,工厂接口本身不去创建对象,而是交给其子类或者是其实现类去创建,将实际创建工作推迟到子类中进行


详情请参考:http://www.cnblogs.com/zhangchenliang/p/3700820.html

代码请参考:http://www.cnblogs.com/mengdd/archive/2013/01/04/2844868.html

抽象工厂模式

优点:

1、抽象工厂模式隔离了具体类的生产,使得客户并不需要知道什么被创建。

2、当一个产品族中的多个对象被设计成一起工作时,它能保证客户端始终只使用同一个产品族中的对象。

3、增加新的具体工厂和产品族很方便,无须修改已有系统,符合“开闭原则”。

 

缺点:

增加新的产品等级结构很复杂,需要修改抽象工厂和所有的具体工厂类,对“开闭原则”的支持呈现倾斜性。



详情请参考:http://haolloyin.blog.51cto.com/1177454/332802

代码请参考:http://www.cnblogs.com/mengdd/archive/2013/01/04/2844868.html


单例模式(Singleton Pattern)

定义:单件模式确保一个类只有一个实例,并提供一个全局访问点。

单件模式常常被用来管理共享的资源,例如数据库连接或者线程池。

主要优点:

1、提供了对唯一实例的受控访问。

2、由于在系统内存中只存在一个对象,因此可以节约系统资源,对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。

主要缺点:

1、由于单利模式中没有抽象层,因此单例类的扩展有很大的困难。

2、单例类的职责过重,在一定程度上违背了“单一职责原则”。

3、滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;如果实例化的对象长时间不被利用,系统会认为是垃圾而被回收,这将导致对象状态的丢失

重点:

1、两个类加载器可能有机会各自创建自己的单例实例,因为每个类加载器都定义了一个命名空间,不同的类加载器加载同一个类,会出现这种情况。

2、继承单例类会有问题,因为单例类的构造器是私有的。





评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值