一、优秀的博文推荐
【吕振宇-设计模式】
二、理解设计模式
地上本没有路,走得人多了也就成了路。设计模式如同此理,它是经验的传承,并非体系;是被前人发现,经过总结形成了一套某一类问题的一般性解决方案。模式的目标是把共通问题中的不变部分和变化部分分离出来,不变的部分就构成了模式。模式是一个经验提取的“准则”,并且在一次一次的实践中得到验证,在不同的层次有不同的模式,小到语言实现,大到架构。在不同的层面上,模式提供不同层面的指导。
我们的目标是追求有效的设计,而设计模式可以为这个目标提供某种参考模型、设计方法。合理的运用设计模式,才是正确的抉择。很多人看过GOF的《Design Patterns》,对这23 种模式也背得滚瓜烂熟。但重要的不是你熟记了多少个模式的名称,关键还在于付诸实践的运用。为了有效地设计,而去熟悉某种模式所花费的代价是值得的,因为很快你会在设计中发现这种模式真的很好,很多时候它令得你的设计更加简单了。真正出色的设计师,懂得判断运用模式的时机。
三、设计模式原则
1、 "开放-封闭"原则(OCP)
概念:Open-Closed Principle原则讲的是:一个软件实体应当对扩展开放,对修改关闭。
优点:
- 通过扩展已有软件系统,可以提供新的行为,以满足对软件的新的需求,使变化中的软件有一定的适应性和灵活性。
- 已有软件模块,特别是最重要的抽象层模块不能再修改,这使变化中的软件系统有一定的稳定性和延续性。
例子:玉帝招安美猴王
当年大闹天宫便是美猴王对玉帝的新挑战。美猴王说:"'皇帝轮流做,明年到我家。'只教他搬出去,将天宫让于我!"对于这项挑战,太白金星给玉皇大帝提出的建议是:"降一道招安圣旨,宣上界来…,一则不劳师动众,二则收仙有道也。"换而言之,不劳师动众、不破坏天规便是"闭",收仙有道便是"开"。招安之道便是玉帝天庭的"开放-封闭"原则。
招安之法的关键便是不允许更改现有的天庭秩序,但允许将妖猴纳入现有秩序中,从而扩展了这一秩序。用面向对象的语言来讲,不允许更改的是系统的抽象层,而允许更改的是系统的实现层。
2、里氏代换原则(LSP)
Liskov Substitution Principle(里氏代换原则):子类型(subtype)必须能够替换它们的基类型。
白马、黑马
反过来的代换不成立
《墨子·小取》说:"娣,美人也,爱娣,非爱美人也……"娣便是妹妹,哥哥喜爱妹妹,是因为两人是兄妹关系,而不是因为妹妹是个美人。因此,喜爱妹妹不等同于喜爱美人。用面向对象语言描述,美人是基类,妹妹是美人的子类。哥哥作为一个有"喜爱()"方法,接受妹妹作为参数。那么,这个"喜爱()"方法一般不能接受美人的实例。
一个违反LSP的简单例子(长方形和正方形)
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
public class Rectangle { private long width; private long height; public void setWidth(long width) { this.width = width; } public long getWidth() { return this.width; } public void setHeight(long height) { this.height = height; } public long getHeight() { return this.height; } } public class Square { private long side; public void setSide(long side) { this.side = side; } public long getSide() { return side; } }
正方形不可以做长方形的子类
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
using System; public class Rectangle { private long width; private long height; public void setWidth(long width) { this.width = width; } public long getWidth() { return this.width; } public void setHeight(long height) { this.height = height; } public long getHeight() { return this.height; } } public class Square : Rectangle { private long side; public void setWidth(long width) { setSide(width); } public long getWidth() { return getSide(); } public void setHeight(long height) { setSide(height); } public long getHeight() { return getSide(); } public long getSide() { return side; } public void setSide(long side) { this.side = side; } } public class SmartTest { public void resize(Rectangle r) { while (r.getHeight() >= r.getWidth() ) { r.setWidth(r.getWidth() + 1); } } }
在执行SmartTest的resize方法时,如果传入的是长方形对象,当高度大于宽度时,会自动增加宽度直到超出高度。但是如果传入的是正方形对象,则会陷入死循环。
代码重构:
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
public interface Quadrangle { public long getWidth(); public long getHeight(); } public class Rectangle : Quadrangle { private long width; private long height; public void setWidth(long width) { this.width = width; } public long getWidth() { return this.width; } public void setHeight(long height) { this.height = height; } public long getHeight() { return this.height; } } public class Square : Quadrangle { private long side; public void setSide(long side) { this.side = side; } public long getSide() { return side; } public long getWidth() { return getSide(); } public long getHeight() { return getSide(); } }
3、依赖倒置原则(DIP)
依赖倒置(Dependence Inversion Principle)原则讲的是:要依赖于抽象,不要依赖于具体。简单的说,依赖倒置原则要求客户端依赖于抽象耦合。原则表述:抽象不应当依赖于细节;细节应当依赖于抽象;要针对接口编程,不针对实现编程。
反面例子:
缺点:耦合太紧密,Light发生变化将影响ToggleSwitch。
解决办法一:
将Light作成Abstract,然后具体类继承自Light。
优点:ToggleSwitch依赖于抽象类Light,具有更高的稳定性,而BulbLight与TubeLight继承自Light,可以根据"开放-封闭"原则进行扩展。只要Light不发生变化,BulbLight与TubeLight的变化就不会波及ToggleSwitch。
缺点:如果用ToggleSwitch控制一台电视就很困难了。总不能让TV继承自Light吧。
解决方法二:
优点:更为通用、更为稳定。
结论:
使用传统过程化程序设计所创建的依赖关系,策略依赖于细节,这是糟糕的,因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象,抽象的稳定性决定了系统的稳定性。
4、 接口隔离原则(ISP)
接口隔离原则(Interface Segregation Principle)讲的是:使用多个专门的接口比使用单一的总接口总要好。换而言之,从一个客户类的角度来讲:一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
实现方法:
1、 使用委托分离接口
2、 使用多重继承分离接口
5、 合成/聚合复用原则(CARP)
合成/聚合复用原则(Composite/Aggregate Reuse Principle或CARP)经常又叫做合成复用原则(Composite Reuse Principle或CRP),就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新对象通过向这些对象的委派达到复用已有功能的目的。简而言之,要尽量使用合成/聚合,尽量不要使用继承。
区分"Has-A"与"Is-A"
"Is-A"是严格的分类学意义上定义,意思是一个类是另一个类的"一种"。而"Has-A"则不同,它表示某一个角色具有某一项责任。
导致错误的使用继承而不是合成/聚合的一个常见的原因是错误的把"Has-A"当作"Is-A"。
例如:
实际上,雇员、经理、学生描述的是一种角色,比如一个人是"经理"必然是"雇员",另外一个人可能是"学生雇员",在上面的设计中,一个人无法同时拥有多个角色,是"雇员"就不能再是"学生"了,这显然是不合理的。
错误源于把"角色"的等级结构与"人"的等级结构混淆起来,误把"Has-A"当作"Is-A"。解决办法:
6、 迪米特法则(LoD)
迪米特法则(Law of Demeter或简写LoD)又叫最少知识原则(Least Knowledge Principle或简写为LKP),也就是说,一个对象应当对其它对象有尽可能少的了解。其它表述: 只与你直接的朋友们通信,不要跟"陌生人"说话,每一个软件单位对其它的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。