《设计模式》之八大设计原则

文章详细阐述了软件设计的几个重要原则,包括依赖倒置原则(DIP)强调高层模块依赖抽象,开闭原则(OCP)提倡对扩展开放、对修改封闭,单一职责原则(SRP)要求类只有一个引起变化的原因,Liskov替换原则(LSP)确保子类可替换基类,接口隔离原则(IPS)主张接口应小而完备,以及优先使用对象组合而非继承,封装变化点和面向接口编程以降低耦合和提高灵活性。
摘要由CSDN通过智能技术生成

1、依赖倒置原则(DIP)

1) 高层模块不应该依赖与低层模块,二者都应该依赖与抽象
高层次模块属于稳定的部分,低层模块属于变化的模块,如果高层模块依赖低层模块,那么会导致高层模块也变的不稳定。都应该依赖与抽象,因为抽象是提炼出来的稳定的部分
2)抽象不应该依赖与实现细节,实现细节应该依赖与抽象
具体的实现细节是属于容易变化的部分,不应该让抽象去依赖实现细节,否则稳定的部分也会变的不稳定。
总结
设计的原则要让容易变化的部分去依赖稳定的部分,不要让稳定的部分去依赖不稳定的部分,这样将会把稳定部分也变不稳定。

2、开闭原则(OCP)

1)对扩展开放,对修改封闭
扩展是对功能的新增,要保证在不修改原有设计的情况进行扩展,这表示是一个好的设计;不要对原有的设计进行修改,因为原有的是已经稳定的部分,新的修改会引入不稳定的因素,使其原本稳定的部分,变得不稳定。
2)类模块应该是可扩展的,但是要不可修改
总结
开闭原则要求对扩展开放,要使扩展变得容易;要对原有的设计避免修改。

3、单一职责原则(SRP)

1)一个类应该只有一个引起它变化的原因
一个类应该让它仅具有一个职责或者功能。设计功能单一的类,而不是大而全的类。
2)变化的方向隐含着一个类的责任
如果一个类出现多个可以引起其变化的原因,或者具有多个不相干的功能,那么就说明类的职责不单一。可将其拆分为多个职责或功能单一的、粒度更小的类。
总结
单一职责原则要求一个类只能有一种引起其变化的原因。

4、Liskov替换原则(LSP)

1)子类必须能够替换它们的基类(is-a)
要求子类要严格按照is-a的方式来设计,即子类不能改变父类的行为约束。程序中所有用到基类的地方,更换为基类都可以正常的运行,且不会影响原来程序的运行逻辑。
2)继承表达抽象
总结
Liskov替换原则,要求子类和父类的关系必须是is-a的关系,破坏此关系,则不能达到子类能够替换基类的效果。

5、接口隔离原则(IPS)

1)不应该强迫客户程序依赖他们不使用的方法
对于不同客户使用的接口可能有差异,此时就仅需要暴露客户需要的接口,对于不使用的接口就要进行封装隐藏。
2)接口应该小而且完备
总结
接口隔离原则侧重的为接口的设计,仅需要提供客户需要的接口即可。

6、优先使用对象组合,而非继承

1)类继承通常为“白箱复用”,类组合通常为“黑箱复用”
继承的关系为is-a,组合的关系为has-a的关系;继承需要了解具体的实现细节,而组合子需要了解组合的对象能做什么即可。
2)继承在某种程度上破坏了封装性,子类父类耦合度高
子类对父类的接口和属性是无条件继承的,且不可选择;继承时子类可以覆盖父类的接口,修改父类接口的具体实现。
3)组合只要求被组合的对象具有良好的封装性,耦合度低
组合只能使用模块提供的公共接口或属性,不能覆盖其接口,或修改其接口的具体实现
总结
在设计阶段要识别和选择使用继承还是组合模式,如果属于is-a的关系或者需要使用多态那么就选择继承关系;如果属于has-a的关系那么就选择组合。

7、封装变化点

1)使用封装来创建对象之间的分界层,让设计者可以在分界层的一侧修改,而不会对另一测产生不良影响。实现层次间的耦合度。
总结
封装变化点即是将稳定的部分和变化的部分分离,从而达到降低耦合度。而且还可以避免稳定的部分和变化的部分相互依赖导致整个稳定部分的不稳定。

8、针对接口编程,而不是针对实现编程

1)不将变量类型声明为某个特定的具体类型,而是声明为某个接口
2)客户程序无需获知对象的具体类型,只需要知道对象所具有的接口
3)减少系统中各部分的依赖关系,从而实现“高内聚,松耦合”的类型设计方案
总结
面向接口编程可以更加方便的实现多态,客户不需要了解具体的实现,只需要了解接口和功能即可。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值