C#设计模式总结
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了C#设计模式总结相关的知识,希望对你有一定的参考价值。
一、引言
经过这段时间对设计模式的学习,自己的感触还是很多的,因为我现在在写代码的时候,经常会想想这里能不能用什么设计模式来进行重构。所以,学完设计模式之后,感觉它会慢慢地影响到你写代码的思维方式。这里对设计模式做一个总结,一来可以对所有设计模式进行一个梳理,二来可以做一个索引来帮助大家收藏。
PS: 其实,很早之前我就看过所有的设计模式了,但是并没有写博客,但是不久就很快忘记了,也没有起到什么作用,这次以博客的形式总结出来,发现效果还是很明显的,因为通过这种总结的方式,我对它理解更深刻了,也记住的更牢靠了,也影响了自己平时实现功能的思维。所以,我鼓励大家可以通过做笔记的方式来把自己学到的东西进行梳理,这样相信可以理解更深,更好,我也会一直写下来,之后打算写WCF一系列文章。
其实WCF内容很早也看过了,并且博客园也有很多前辈写的很好,但是,我觉得我还是需要自己总结,因为只有这样,知识才是自己的,别人写的多好,你看了之后,其实还是别人了,所以鼓励大家几点(对于这几点,也是对自己的一个提醒):
- 要动手实战别人博客中的例子;
- 实现之后进行总结,可以写博客也可以自己记录云笔记等;
- 想想能不能进行扩展,进行举一反三。
二、 设计原则
使用设计模式的根本原因是适应变化,提高代码复用率,使软件更具有可维护性和可扩展性。并且,在进行设计的时候,也需要遵循以下几个原则:单一职责原则、开放封闭原则、里氏代替原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。下面就分别介绍了每种设计原则。
2.1 单一职责原则
就一个类而言,应该只有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,也会影响复用性。
2.2 开闭原则(Open-Closed Principle)
开闭原则即OCP(Open-Closed Principle缩写)原则,该原则强调的是:一个软件实体(指的类、函数、模块等)应该对扩展开放,对修改关闭。即每次发生变化时,要通过添加新的代码来增强现有类型的行为,而不是修改原有的代码。
符合开闭原则的最好方式是提供一个固有的接口,然后让所有可能发生变化的类实现该接口,让固定的接口与相关对象进行交互。
2.3 里氏代替原则(Liskov Substitution Principle)
Liskov Substitution Principle,LSP(里氏代替原则)指的是子类必须替换掉它们的父类型。也就是说,在软件开发过程中,子类替换父类后,程序的行为是一样的。只有当子类替换掉父类后,此时软件的功能不受影响时,父类才能真正地被复用,而子类也可以在父类的基础上添加新的行为。为了就来看看违反了LSP原则的例子,具体代码如下所示:
public class Rectangle { public virtual long Width { get; set; } public virtual long Height { get; set; } } // 正方形 public class Square : Rectangle { public override long Height { get { return base.Height; } set { base.Height = value; base.Width = value; } } public override long Width { get { return base.Width; } set { base.Width = value; base.Height = value; } } } class Test { public void Resize(Rectangle r) { while (r.Height >= r.Width) { r.Width += 1; } } var r = new Square() { Width = 10, Height = 10 }; new Test().Resize(r); }
上面的设计,正如上面注释的一样,在执行SmartTest的resize方法时,如果传入的是长方形对象,当高度大于宽度时,会自动增加宽度直到超出高度。但是如果传入的是正方形对象,则会陷入死循环。此时根本原因是,矩形不能作为正方形的父类,既然出现了问题,可以进行重构,使它们俩都继承于四边形类。重构后的代码如下所示:
// 四边形 public abstract class Quadrangle { public virtual long Width { get; set; } public virtual long Height { get; set; } } // 矩形 public class Rectangle : Quadrangle { public override long Height { get; set; } public override long Width { get; set; } } // 正方形 public class Square : Quadrangle { public long _side; public Square(long side) { _side = side; } } class Test { public void Resize(Quadrangle r) { while (r.Height >= r.Width) { r.Width += 1; } } static void Main(string[] args) { var s = new Square(10); new Test().Resize(s); } }
2.4 依赖倒置原则
依赖倒置(Dependence Inversion Principle, DIP)原则指的是抽象不应该依赖于细节,细节应该依赖于抽象,也就是提出的 “面向接口编程,而不是面向实现编程”。这样可以降低客户与具体实现的耦合。
2.5 接口隔离原则
接口隔离原则(Interface Segregation Principle, ISP)指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责,而应把每个职责分离到多个专门的接口中,进行接口分离。过于臃肿的接口是对接口的一种污染。
2.6 合成复用原则
合成复用原则(Composite Reuse Principle, CRP)就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说,就是要尽量使用合成/聚合,尽量不要使用继承。
要使用好合成复用原则,首先需要区分"Has—A"和“Is—A”的关系。
“Is—A”是指一个类是另一个类的“一种”,是属于的关系,而“Has—A”则不同,它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.例如:
实际上,雇员、经历、学生描述的是一种角色,比如一个人是“经理”必然是“雇员”。在上面的设计中,一个人无法同时拥有多个角色,是“雇员”就不能再是“学生”了,这显然不合理,因为现在很多在职研究生,即使雇员也是学生。
上面的设计的错误源于把“角色”的等级结构与“人”的等级结构混淆起来了,误把“Has—A”当作"Is—A"。具体的解决方法就是抽象出一个角色类:
2.7 迪米特法则
迪米特法则(Law of Demeter,LoD)又叫最少知识原则(Least Knowledge Principle,LKP),指的是一个对象应当对其他对象有尽可能少的了解。也就是说,一个模块或对象应尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,扩展起来更加容易。
关于迪米特法则其他的一些表述有:只与你直接的朋友们通信;不要跟“陌生人”说话。
外观模式(Facade Pattern)和中介者模式(Mediator Pattern)就使用了迪米特法则。
以上是关于C#设计模式总结的主要内容,如果未能解决你的问题,请参考以下文章