设计模式之SOLID原则再回首

    本科阶段学过设计模式,那时对设计模式的五大原则——SOLID原则的概念与理解还是比较模糊,此时过去了2年时间,在学习《高级软件工程》课程中老师又提到了设计模式,课程中还详细讨论了五大原则的过程,这次SOLID原则再回首作者提出了一些更通俗的理解吧~

一. 什么是设计模式？

   
那么,什么是设计模式呢?

其中设计模式的SOLID原则(Principles)如下：

二. 单一职责原则

   
单一职责原则(Single Responsibility Principle,SRP)思想:就一个类而言,应仅有一个引起它变化的原因(一个类只有一个职责);每一个引起类变化的原因就是一个职责,当类具有多职责时,应该把多余职责分离出去,分别创建类来完成.

    就我而言,在做很多项目时都喜欢在一个类中去增加各种各样的功能,C#窗体应用程序中会在Form类中增加各式各样的代码,当需求变更时,总需要更改这个窗体类,代码越来越长,维护很麻烦且灵活性很低.

三. 开闭原则

   开闭原则(Open Closed Principle,OCP)思想:对功能扩展是开放的(增加新功能),但对修改原功能代码是关闭的.在进行扩展(类\模块\函数都可以扩展)时,不需要对原来的程序进行修改,即已有东西不变,可添加新功能.

它的好处是灵活可用,可加入新功能,新模块满足不断变化的新需求,由于不修改软件原来的模块,不用担心软件的稳定性.主要原则包括：

   
1.抽象原则

    把系统的所有可能的行为抽象成一个底层,由于可从抽象层导出多个具体类来改变系统行为,因此对于可变部分系统设计对扩展是开放的.

   
2.可变性封装原则

对系统所有可能发生变化的部分进行评估和分类,每个可变的因素都单独进行封装.

   正如《大话设计模式》中所说：“我们在做任何系统时,需求都会存在一定的变化,那么如何面对需求变化时,设计软件可以相对容易修改,而不是把整个项目推倒重来.开闭原则可以让设计面对需求变化时保持相对稳定,从而使得系统在第一个版本后不断推出新的版本.”

   
但是无论模块怎么封装,都会存在一些无法对之封装的变化,既然不可能完全封装,设计人员必须对设计的模块应该对哪种变化封装做出选择,他需要通过猜测最有可能发生的变化种类,然后构造抽象来隔离那些变化.通常设计人员会在发生小变化时,就及早去想办法应对发生更大变化的可能,即等到变化时立即采取行动.当变化发生时就创建抽象来隔离以后发生同类变化.

   
例子理解：(源自<<大话设计模式>>)

   
香港回归采用"一国两制"的体制就是开闭原则的代表例子,社会主义制度是不可更改,但可以增加新的制度实现共和.再如一个计算器的例子,原来客户端只有加法运算,现在需要添加新的功能减法,此时如果你去修改原来类就会违背"开放-封闭原则",而且当添加很多新的运算时,这样的代码很难维护.

    此时你需要重构程序,增加一个抽象类的运算类,通过继承或多态等隔离具体加法、减法与client耦合,面对需求变化,对程序的改动是通过增加新代码进行的,而不是更改现有的代码,这就是开闭原则的精髓.

    PS:想到以前图像处理软件,每学习一章新处理如图像灰度、增强、采样、二值化等,就在原来的基础上不断增加新的函数实现,而且最后一个.cpp文件4000多行,简直无法直视啊！可能还是我实际项目做得比较少的原因,拿到一个项目如何去规划、设计的理解依然不够,等工作几年后我再回来写一些实际经验的设计思想文章吧,拭目以待~

四. 里氏替换原则

里氏替换原则(Liskov Substitution Principle,LSP)思想:继承必须确保父类所拥有的性质在子类中仍然成立,当一个子类的实例能够替换任何其父类的实例时,它们之间才具有is-a-kind-of-A关系.只有当一个子类(派生类)可以替换掉其父类(基类)而软件功能不受影响时,基类才能被复用,派生类也才能在基类的基础上增加新的行为.

其本质是在同一个继承体系中的对象应该有共同的行为特征.

换句话说,一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且觉察不出父类对象和子类对象的区别,在软件中把父类都替换成它的子类,程序的行为没有变化,子类必须能够替换掉它们的父类型.

例子理解:

父类为猫,子类有黑猫和白猫,如果一个方法使用于猫如捉老鼠,则必然使用于黑猫和白猫.再如<<大话设计模式>>中的问题“企鹅是鸟吗?”

生物学:企鹅属于鸟类

LSP原则:企鹅不属于鸟类,因为企鹅不会"飞",所以企鹅不能继承鸟类

    正是因为该原则,使得继承复用成为了可能,只有当子类可以替换掉父类,软件单位的功能不到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为.由于子类的可替换性才使得父类类型的模块在无需修改的情况下就可以扩展,可以说由于里氏替换原则才使得开闭原则成为可能.

五. 依赖倒置原则

依赖倒置原则(Dependence Inversion Principle)思想：高层模块不应该依赖低层模块,二者都应该依赖于抽象.

1.高层模块只应该包含重要的业务模型和策略选择

2.低层模块则是不同业务和策略的实现

3.高层抽象不依赖高层和底层模块的具体实现,最多依赖低层的抽象

4.低层抽象和实现也只依赖于高层抽象

换句话说：要依赖于抽象,而不要依赖于具体实现;高层是功能和策略,低层是具体实现;编程程序语言就是需要针对接口编程而不要针对实现编程.

顺便说说与设计模式相关的两个知识点:

1.面向对象的四个优点：可维护、可扩展、可服用、灵活性好

2.高内聚低耦合：高内聚就是一个模块内各个元素彼此结合紧密程度高,一个软件模块只负责一个任务,也就是单一职责原则,提高模块的独立性;低耦合就是软件结构内不同模块之间相互连接的程度低,模块与模块之间尽可能独立存在,模块与模块之间的接口尽量少而且简单,具有更好的复用性和扩展性.

例子理解:(强推&参考博客园cbf4life的文章——依赖倒置原则)

下图表示司机驾驶奔驰车的类图.

   代码如下所示,司机通过调用奔驰车run方法开动汽车,通过client场景描述eastmount开奔驰车.

//司机类
public class Driver {
    //司机主要职责驾驶汽车
    public void drive(Benz benz) {
        benz.run();
    }
}
//奔驰类
public class Benz {
    public void run() {
        System.out.printIn("奔驰汽车跑");
    }
}
//场景类
public class Client {
    public static void main(String[] args) {
        //eastmount开奔驰车
        Driver eastmount = new Driver();
        Benz benz = new Benz();
        eastmount.drive(benz);
    }
}

    现在司机eastmount不仅要开奔驰车,还要开宝马车,又该怎么实现呢?自定义宝马汽车类BMW,但是不能开,因为eastmount没有开宝马车的方法,出现的问题就是：

   
代码如下,接口只是一个抽象化的概念,是对一类事物的抽象描述,具体的实现代码由相应的类来完成,所以还需要定义Driver实现类;同时在IDriver接口中通过传入ICar接口实现抽象之间的依赖关系,Driver实现类也传入了ICar接口,具体开的是哪种车需要在高层模型中声明,具体开发方法在BMW和Benz类中定义.

//司机接口 驾驶汽车 抽象
public interface IDriver {
    public void drive(ICar car);
}
//司机类 具体实现
public class Driver implements IDriver{
    //司机的主要职责就是驾驶汽车
    public void drive(ICar car){
        car.run();
    }
}
//汽车接口
public interface ICar {
    public void run();
}
//奔驰车类
public class Benz implements ICar{
    public void run(){
        System.out.println("奔驰汽车跑");
    }
}
//宝马车类
public class BMW implements ICar{
    public void run(){
        System.out.println("宝马汽车跑");
    }
}
//实现eastmount开宝马车
public class Client {
    public static void main(String[] args) {
        IDriver eastmount = new Driver();
        ICar bmw = new BMW();
        eastmount.drive(bmw);
    }
}

   由于"抽象不应该依赖细节",所以我们认为抽象(ICar接口)不依赖BMW和Benz两个实现类(细节),在高层次的模块中应用都是抽象,Client就属于高层次业务逻辑,它对于低层次模块的依赖都是建立在抽象上,eastmount都是以IDriver接口类型进行操作,屏蔽了细节对抽象的影响,现在开不同类型的车,只需要修改业务场景类即可实现:

六. 接口隔离原则

接口隔离原则(Interface Segregation Principle,ISP)思想：多个和客户相关的接口要好于一个通用接口.如果一个类有几个使用者,与其让这个类再如所有使用这需要使用的所有方法,还不如为每个使用者创建一个特定接口,并让该类分别实现这些接口.

例子理解:(推荐&引用zhengzhb博客——接口隔离原则)

如下图所示,类A依赖接口I中方法1\方法2\方法3,类B是对类A依赖的实现,类C依赖于接口I中的方法方法1\方法4\方法5,类D是对类C依赖的实现.对于类B和类D中都存在用不到的方法,但是由于实现了接口I,所以需要实现这些不用的方法.(代码见原文链接)

   
可以发现接口过于臃肿,只要接口中出现的方法,不管对依赖于它的类有没有用,实现类中都必须去实现这些方法,如类B中方法4和方法5,类D中方法2和方法3,显然这样的设计不适用.

设计如下修改为符合接口隔离原则,必须对接口I进行拆分,拆分为三个接口I1\I2\I3.此时实现类B和类D中方法都是需要使用的方法,这就体现了建立单一接口而不是庞大接口的好处.(源码见上面的链接)

   接口隔离原则即尽量细化接口,接口中的方法尽量少,为各个类建立专用的接口,而不是试图去建立一个庞大而臃肿的接口提供所有依赖于他的类去调用.说到这里,很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。

其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口,主要针对抽象,针对程序整体框架的构建.

   总结:这是一篇关于回顾设计模式SOLID五大原则的文章,我非常喜欢文章中的例子,每个例子都是我精选了描述模式的,通过Modom讲述了单一职责原则、加减法计算器讲述了开闭原则、企鹅动物讲述了里氏替换原则、通过Driver和Car实现了依赖倒置原则,最后讲述了接口隔离原则.希望文章对大家有所帮助,尤其是学习设计模式的同学和代码写得不太规范或需要重构的同学,如果有错误或不足之处,还请海涵~

4.zhengzhb博客——接口隔离原则