设计模式:单一职责原则、开放-封闭原则以及依赖倒置原则

在设计代码中,我们有许多可以依照的设计模式,让我把整个项目的逻辑结构变得清晰易于维护。当然,在设计模式中我们不只有各种模式,还有许多设计的原则,虽然他们不是代码架构的模板,但是这些原则却时刻提醒我们提高代码质量和防止未来麻烦。这次我就将单一职责原则、开放-封闭原则以及依赖倒转原则进行解释。

一、单一职责原则

专业解释:单一职责原则(SRP),就一个类而言,应该仅有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏。

其实很好理解,举个例子,就像需要写一个能够适用于Windows的可视化界面程序,很多人会将业务逻辑代码和界面代码混写在一起,这样做确实可以将任务完成,但是这样子会出现一个问题,当我需要一个同样的能够在IOS上运行的可视化界面程序,这个时候我就需要对整个程序进行重构。如果在最开始我就讲业务逻辑代码和界面代码进行分离,那么当界面代码需要变化的时候,就对业务逻辑代码影响不大,从而起到了复用的效果。

当然,这样说起来比做起来容易,软件设计真正要做的有许多内容,就是发现职责并把那些职责分离,其实去判断是否分离也不难,那就是如果你能找到多于一个动机去改变这个类,那么这个类就有多于一个职责。

二、开放-封闭原则

专业解释:开放-封闭原则,是说软件实体(类、模块、函数等等),应该可以扩展,但是不可以修改。对于扩展是是开放的,对于修改是封闭的。

开放-封闭原则给我们的启发是,如何设计才能面对需求的改变却可以保持相对稳定,从而可以使系统才在第一个版本以后不断推出新的版本。这个原则其实和单一职责原则有一定相似的地方,都是将程序尽可能的模块化,降低耦合度,但是开发-封闭原则还强调为以后的扩展做准备。就像我们在之前提到过的例子,写一个计算器程序,最开始的需求只有加减乘除,但以后可能会增加如根号等需求,基于这一点,我们就需要考虑到开放-封闭原则,使用一些方式达到在需求变动的时候,降低我们的工作量,从而我们想到了使用简单工厂模式。

绝对的对修改关闭是不可能的,无论模块是多么“封闭”,都会存在一些无法对之封闭的变化,既然不可能完全封闭,设计人员就应该对他设计的模块应该对哪种变化封闭做出选择,他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化。

当然我们不可能在设计程序之初就预测好所有的变化,所以我们在最初编写代码时,假设变化不会发生,当变化发生时,我们就构造抽象来隔离以后发生的同类变化。

开放-封闭原则是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大的好处,也就是可维护、可扩展、可复用、灵活性好,开发人员就应该对程序中出现频繁变化的那部分做出抽象,然而,对于应用程序中每一个部分刻意的进行抽象并不是一个好主意,拒绝不成熟的抽象和抽象本身一样重要。

三、依赖倒置原则

专业解释:高层模块不应该依赖底层模块,两个都应该依赖抽象。抽象不应该依赖于细节,细节应该依赖抽象。依赖倒置可以说是面向对象设计的标志,用那种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象程序编程而不是针对细节编程,即程序中所有依赖关系狗屎终止于抽象类或接口,那就是面向对象设计,反之就是过程化设计。

以修电脑为例,更换CPU、内存卡等,其实其中就有好几种面向对象的几个设计原则。如我们之前讲到的单一职责原则,电脑的内存坏了,不应该成为更换CPU的理由,他们之间各自的职责很明确,再比如封闭-开放原则,内存不够只要插槽足够就可以添加,硬盘不够可以用移动硬盘,PC的接口是有限的,但只要软件系统设计的好,却可以无限的扩展。而在依赖倒置原则中,抽象不应该依赖细节,细节应该依赖于抽象,说白了就是针对接口编程,要对实现编程,无论主板、CPU、硬盘都是针对接口设计的,如果针对现实来设计,那么在设计主板CPU等时,就需要知道不同牌子的不同接口。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 程序猿惹谁了 设计师:白松林 返回首页