欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2023-11-18 21:36:10
本文我们要谈的七大原则,即:单一职责,里氏替换,迪米特法则,依赖倒转,接口隔离,合成/聚合原则,开放-封闭 。 1.   开闭原则(open-clos...

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

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

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