C#面向对象设计的七大原则

时间:2022-01-20 04:34:23

本文我们要谈的七大原则,即:单一职责,里氏替换,迪米特法则,依赖倒转,接口隔离,合成/聚合原则,开放-封闭

1.   开闭原则(open-closed principle, ocp)

定义:软件实体应当对扩展开放,对修改关闭。这句话说得有点专业,更通俗一点讲,也就是:软件系统中包含的各种组件,例如模块(modules)、类(classes)以及功能(functions)等等,应该在不修改现有代码的基础上,去扩展新功能。开闭原则中原有“开”,是指对于组件功能的扩展是开放的,是允许对其进行功能扩展的;开闭原则中“闭”,是指对于代码的修改是封闭的,即不应该修改原有的代码。

问题由来:凡事的产生都有缘由。我们来看看,开闭原则的产生缘由。在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。这就对我们的整个系统的影响特别大,这也充分展现出了系统的耦合性如果太高,会大大的增加后期的扩展,维护。为了解决这个问题,故人们总结出了开闭原则。解决开闭原则的根本其实还是在解耦合。所以,我们面向对象的开发,我们最根本的任务就是解耦合。 

解决方法:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。 

小结:开闭原则具有理想主义的色彩,说的很抽象,它是面向对象设计的终极目标。其他几条原则,则可以看做是开闭原则的实现。我们要用抽象构建框架,用实现扩展细节。

2.    单一职责原则(single responsibility principle)

定义:一个类,只有一个引起它变化的原因。即:应该只有一个职责。

每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起,会影响复用性。例如:要实现逻辑和界面的分离。需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。 

问题由来:类t负责两个不同的职责:职责p1,职责p2。当由于职责p1需求发生改变而需要修改类t时,有可能会导致原本运行正常的职责p2功能发生故障。 

解决方法:分别建立两个类t1、t2,使t1完成职责p1功能,t2完成职责p2功能。这样,当修改类t1时,不会使职责p2发生故障风险;同理,当修改t2时,也不会使职责p1发生故障风险。

3.    里氏替换原则(liskov substitution principle)

定义:子类型必须能够替换掉它们的父类型。注意这里的能够两字。有人也戏称老鼠的儿子会打洞原则。

问题由来:有一功能p1,由类a完成。现需要将功能p1进行扩展,扩展后的功能为p,其中p由原有功能p1与新功能p2组成。新功能p由类a的子类b来完成,则子类b在完成新功能p2的同时,有可能会导致原有功能p1发生故障。 

解决方法:类b继承类a时,除添加新的方法完成新增功能p2外,尽量不要重写父类a的方法,也尽量不要重载父类a的方法 

小结:所有引用父类的地方必须能透明地使用其子类的对象。子类可以扩展父类的功能,但不能改变父类原有的功能,即:子类可以实现父类的抽象方法,子类也中可以增加自己特有的方法,但不能覆盖父类的非抽象方法。当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

4.    迪米特法则(law of demeter)

 定义:迪米特法则又叫最少知道原则,即:一个对象应该对其他对象保持最少的了解。如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。简单定义为只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。

问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。

最早是在1987年由美国northeastern university的ian holland提出。通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。 

解决方法:尽量降低类与类之间的耦合。 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。 

迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系。故过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。 

5.    依赖倒置原则(dependence inversion principle)

定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。中心思想是面向接口编程 

问题由来:类a直接依赖类b,假如要将类a改为依赖类c,则必须通过修改类a的代码来达成。这种场景下,类a一般是高层模块,负责复杂的业务逻辑;类b和类c是低层模块,负责基本的原子操作;假如修改类a,会给程序带来不必要的风险。 

解决方法:将类a修改为依赖接口i,类b和类c各自实现接口i,类a通过接口i间接与类b或者类c发生联系,则会大大降低修改类a的几率。 

在实际编程中,我们一般需要做到如下3点:

1). 低层模块尽量都要有抽象类或接口,或者两者都有。

2). 变量的声明类型尽量是抽象类或接口。

3). 使用继承时遵循里氏替换原则。 

采用依赖倒置原则尤其给多人合作开发带来了极大的便利,参与协作开发的人越多、项目越庞大,采用依赖导致原则的意义就越重大。 

小结:依赖倒置原则就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。 

6.    接口隔离原则(interface segregation principle)

定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。 

问题由来:类a通过接口i依赖类b,类c通过接口i依赖类d,如果接口i对于类a和类b来说不是最小接口,则类b和类d必须去实现他们不需要的方法 

解决方法:1、 使用委托分离接口。2、 使用多重继承分离接口。3.将臃肿的接口i拆分为独立的几个接口,类a和类c分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。 

举例说明:

下面我们来看张图,一切就一目了然了。

C#面向对象设计的七大原则  

这个图的意思是:类a依赖接口i中的方法1、方法2、方法3,类b是对类a依赖的实现。类c依赖接口i中的方法1、方法4、方法5,类d是对类c依赖的实现。对于类b和类d来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口i,所以也必须要实现这些用不到的方法

修改后:

 C#面向对象设计的七大原则

如果接口过于臃肿,只要接口中出现的方法,不管对依赖于它的类有没有用处,实现类中都必须去实现这些方法,这显然不是好的设计。如果将这个设计修改为符合接口隔离原则,就必须对接口i进行拆分。在这里我们将原有的接口i拆分为三个接口

小结:我们在代码编写过程中,运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。设计接口的时候,只有多花些时间去思考和筹划,就能准确地实践这一原则。 

7.   合成/聚合原则(composite/aggregate reuse principle,carp)

定义:也有人叫做合成复用原则,及尽量使用合成/聚合,尽量不要使用类继承。换句话说,就是能用合成/聚合的地方,绝不用继承。 

为什么要尽量使用合成/聚合而不使用类继承?

1. 对象的继承关系在编译时就定义好了,所以无法在运行时改变从父类继承的子类的实现

2. 子类的实现和它的父类有非常紧密的依赖关系,以至于父类实现中的任何变化必然会导致子类发生变化

3. 当你复用子类的时候,如果继承下来的实现不适合解决新的问题,则父类必须重写或者被其它更适合的类所替换,这种依赖关系限制了灵活性,并最终限制了复用性。

总结:这些原则在设计模式中体现的淋淋尽致,设计模式就是实现了这些原则,从而达到了代码复用、增强了系统的扩展性。所以设计模式被很多人奉为经典。我们可以通过好好的研究设计模式,来慢慢的体会这些设计原则。