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

C#设计模式学习笔记:设计原则

程序员文章站 2022-03-25 18:05:09
本笔记摘抄自:https://www.cnblogs.com/PatrickLiu/p/8287784.html,记录一下学习过程以备后续查用。 写代码也是有原则的,我们之所以使用设计模式,主要是为了适应变化,提高代码复用率,使软件更具有可维护性和可扩展性。如果我们能更好的理 解这些设计原则,对我们 ......

    本笔记摘抄自:https://www.cnblogs.com/patrickliu/p/8287784.html,记录一下学习过程以备后续查用。

    写代码也是有原则的,我们之所以使用设计模式,主要是为了适应变化,提高代码复用率,使软件更具有可维护性和可扩展性。如果我们能更好的理

解这些设计原则,对我们理解面向对象的设计模式也是有帮助的,因为这些模式的产生是基于这些原则的。

    C#设计模式学习笔记:设计原则

    设计原则包括:单一职责原则(srp)、开闭原则(ocp)、里氏替换原则(lsp)、依赖倒置原则(dip)、接口隔离原则(isp)、合成复用原

则(crp)、迪米特法则(lod)。

    下面我们就分别介绍这七种设计原则:

    一、单一职责原则(srp)

    1)srp(single responsibilities principle)的定义:就一个类而言,应该仅有一个引起它变化的原因。简而言之,就是功能要单一。

    2)如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致

脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。(敏捷软件开发)

    3)软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。

    小结:单一职责原则(srp)可以看做是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的

原因。责任过多,引起它变化的原因就越多,这样就会导致职责依赖,大大损伤其内聚性和耦合度。

    二、开闭原则(ocp)

    1)ocp(open-close principle)的定义:就是说软件实体(类、方法等等)应该可以扩展(扩展可以理解为增加),但是不能在原来的方法或者类上修

改,也可以这样说,对增加代码开放,对修改代码关闭。

    2)ocp的两个特征: 对于扩展(增加)是开放的,因为它不影响原来的,这是新增加的。对于修改是封闭的,如果总是修改,逻辑会越来越复杂。

    小结:开闭原则(ocp)是面向对象设计的核心思想。遵循这个原则可以为我们面向对象的设计带来巨大的好处:可维护(维护成本小、做管理简

单、影响最小)、可扩展(有新需求,增加就好)、可复用(不耦合,可以使用以前代码)、灵活性好(维护方便、简单)。开发人员应该仅对程序中

出现频繁变化的那些部分做出抽象(但是不能过激,对应用程序中的每个部分都刻意地进行抽象同样也不是一个好主意,拒绝不成熟的抽象和抽象本身

一样重要)。

    三、里氏替换原则(lsp)

    1)lsp(liskov substitution principle)的定义:子类型必须能够替换掉它们的父类型。更直白的说,lsp是实现面向接口编程的基础。

    小结:任何基类可以出现的地方,子类一定可以出现,所以我们可以实现面向接口编程。 lsp是继承复用的基石,只有当子类可以替换掉基类,软件

的功能不受到影响时,基类才能真正被复用,而子类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充,实现开闭原则的关键步

骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。

    里氏替换原则的经典反例:正方形不是长方形、玩具枪不能杀人、鸵鸟不会飞。

    四、依赖倒置原则(dip)

    1)dip(dependence inversion principle)的定义:抽象不应该依赖细节,细节应该依赖于抽象。简单说就是,我们要针对接口编程,而不要针对实现

编程。

    2)高层模块不应该依赖低层模块,两个都应该依赖抽象,因为抽象是稳定的。抽象不应该依赖具体(细节),具体(细节)应该依赖抽象。

    小结:依赖倒置原则其实可以说是面向对象设计的标志,如果在我们编码的时候考虑的是面向接口编程,而不是简单的功能实现,体现了抽象的稳定

性,只有这样才符合面向对象的设计。

    五、接口隔离原则(isp)

    1)接口隔离原则(interface segregation principle, isp)指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担

过多的职责,而应把每个职责分离到多个专门的接口中,进行接口分离,过于臃肿的接口是对接口的一种污染。

    2)使用多个专门的接口比使用单一的总接口要好。

    3)一个类对另外一个类的依赖性应当是建立在最小的接口上的。

    4)一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染。

    5)“不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。”这个说得很明白了,再通俗点说,不要强迫客户使用它们

不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

    小结:接口隔离原则(isp)告诉我们,在做接口设计的时候,要尽量设计的接口功能单一,功能单一,使它变化的因素就少,这样就更稳定。其实这

体现了高内聚、低耦合的原则,这样做也避免接口的污染。

    六、合成复用原则(crp)

    1)组合复用原则(composite reuse principle, crp)就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分,新对象通过向这些

对象的委派达到复用已用功能的目的。简单地说,就是要尽量使用合成/聚合,尽量不要使用继承。

    2)要使用好组合复用原则,首先需要区分”has--a”和“is--a”的关系。“is--a”是指一个类是另一个类的“一种”,是属于的关系,而“has--a”则不同,它表

示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“has--a”当成“is--a”。例如:鸡是动物,这就是“is-a”的表现,

某人有一支手枪,people类型里面包含一个gun类型,这就是“has-a”的表现。

    小结:合成复用原则可以使系统更加灵活,类与类之间的耦合度降低,一个类的变化对其他类造成的影响相对较少,因此一般首选使用合成来实现复

用;其次才考虑继承,在使用继承时,需要严格遵循里氏替换原则,有效使用继承会有助于对问题的理解,降低复杂度,而滥用继承反而会增加系统构

建和维护的难度以及系统的复杂度,因此需要慎重使用继承复用。

    七、迪米特法则(law of demeter)

    1)迪米特法则(law of demeter,lod)又叫最少知识原则(least knowledge principle,lkp),指的是一个对象应当对其他对象有尽可能少的了

解。也就是说,一个模块或对象应尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,

扩展起来更加容易。

    2)关于迪米特法则其他的一些表述有:只与你直接的朋友们通信,不要跟“陌生人”说话。

    3)外观模式(facade pattern)和中介者模式(mediator pattern)就使用了迪米特法则。

    小结:迪米特法则的初衷是降低类之间的耦合,实现类型之间的高内聚、低耦合,这样可以解耦。但是凡事都有度,过分的使用迪米特原则,会产生

大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。

 

    设计原则博文推荐: