设计模式之六大设计原则

内容纲要

本文章参考《设计模式之禅》一书,用自己的话进行总结,可以当做笔记,以后回顾起来看这篇就够了(不知道会不会成了多篇)。

概述

需求的变化不可控,如何让代码适应变化、不在一次次迭代中变成一团乱麻?设计模式给了我们指导。
设计模式是前辈们在实践中总结的一套可以反复使用的经验。它可以提高代码的可重用性、增强系统可维护性,以及解决一系列复杂问题。
前辈们首先提出了6大设计原则作为纲领,然后具体23种设计模式中给了具体指导。
设计模式可以理解为是一种哲学,而非工具,所以使用起来没有好坏之分,代码设计成什么样完全取决于你对设计模式和对你的需求的理解。
这篇文章只能讲一下是什么、为什么,想要游刃有余的使用只能通过不断的实践~

六大设计原则

单一职责原则

单一职责(Single Responsibility Principle SRP原则)又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中提出的。这里的职责是指类变化的原因,单一职责原则规定一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分(There should never be more than one reason for a class to change)。
通俗的说,自己只负责自己的事,不需要理会别人的事。上例子:

用户系统,将上述的IUserInfo,分开成为IUserBO(用户信息)和IUserBiz(用户行为):


这个原则就说完了^_^。

此外强调一下,职责单一,是一个单元内只放会由仅一个原因引起变化的内容,判断有几个原因引起变化,可以看第二个例子:

一个简单的电话接口,三个方法分别负责拨通电话、通话和挂电话。其中通话实现的是数据传送,接通和挂断则是协议相关;因此数据传送和协议的变化都会引起这个接口的变化,按照单一职责原则就可以进行拆分:

在实践中,主要应用在接口和方法设计中,在类中的应用要考虑实际情况,如果为了这个原则带来更高的复杂性(类太多),或影响工期什么的,就得不偿失了,其他原则也是如此,主要在一个trade off^_^。

里氏替换原则

Liskov Substitution Principle(LSP原则)由麻省理工学院计算机科学实验室的里斯科夫(Liskov)女士在 1987 年的“面向对象技术的高峰会议”(OOPSLA)上发表的一篇文章《数据抽象和层次》(Data Abstraction and Hierarchy)里提出来的,她提出:继承必须确保超类所拥有的性质在子类中仍然成立(Inheritance should ensure that any property proved about supertype objects also holds for subtype objects)。
我们知道在继承中,子类拥有父类的所有方法和属性,减少了创建类的工作量,提高了代码的重用性;子类在拥有父类所有功能的基础上,还可以添加自己的功能,提高了代码的扩展性。但也降低了代码的灵活性(子类受父类约束),增强了耦合性(父类的修改影响子类)。LSP原则的引入,将继承的特性扬长避短。

定义:只要父类出现的地方就可以替换为子类,而且不会出现错误,使用者不需要知道使用的是父类还是子类;反过来在使用子类的地方试图用父类替换则可能会出现错误,通俗来讲就是子类可以扩展父类的功能,但不能改变父类原有的功能,LSP原则是实现开闭原则的重要方式之一。

LSP原则为良好的继承制定了规范,也就是什么时候应该使用继承,什么时候不应该使用继承,以及其中蕴含的原理。体现在四个方面:

  1. 子类必须实现父类的抽象方法,但不得重写(覆盖)父类的非抽象(已实现)方法;
    若子类不完全对父类的方法进行实例化,那么子类就不能被实例化;
    父类中已实现的方法其实是一种已定好的规范和契约,若子类覆写则可能会带来意想不到的错误。eg:初始化父类和子类后,调用同一方法,行为不同。
    有时候父类有多个子类,但在这些子类中有一个特例。要想满足里氏替换原则,又想满足这个子类的功能时,有的伙伴可能会修改父类的方法。但是,修改了父类的方法又会对其他的子类造成影响,产生更多的错误。这时可以为这个特例创建一个新的父类,这个新的父类拥有原父类的部分功能,又有不同的功能。这样既满足了里氏替换原则,又满足了这个特例的需求。

  2. 子类中可以增加自己特有的方法。

  3. 子类在覆写或实现父类方法时,输入参数可以比父类宽松。
    这实际上是重载,因为子类的入参类型和父类不一样。若子类入参宽(Map),父类入参窄(HashMap),则通过父类实例和子类实例调用同一方法名,传入HashMap类型入参时,执行的都是父类方法;
    反之,子类定义入参HashMap,父类定义入参Map后,传入HashMap类型入参,通过父类实例调用的是父类方法,而用子类实例调用的方法是子类方法,父类方法没有被重写的情况下,子类方法被调用了,造成逻辑混乱~

  4. 子类在覆写或实现父类方法时,返回值要比父类严格。
    这样可以实现不同子类实例调用方法能返回各自所需的对象类型。

依赖倒置原则

Dependence Inversion Principle(DIP原则)是 Object Mentor 公司总裁罗伯特·马丁(Robert C.Martin)于 1996 年在 C++ Report 上发表文章提出的。
该原则定义为:高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象;本质就是要面向接口编程,不要面向实现编程。这样来实现各类或模块间的彼此独立,实现模块间的松耦合。
“倒置”的解释:“依赖正置”就是类间的依赖使用实现类来依赖,相应的,“倒置”就是指类间通过接口来实现依赖。

用一个例子来看面向实现编程和面向接口编程:
(原始开奔驰图)

上图司机类通过奔驰类来实现driver方法,使司机可以开奔驰车。但想让司机也能开宝马,就需要修改司机类,导致系统可维护性降低。


改为司机通过ICar接口来控制开什么车,体现了抽象不依赖细节。这样一来司机想换个车开,只需要修改client,不侵入原有的司机逻辑。

依赖的三种写法:

  1. 构造函数传递依赖对象
    public interface IDriver {
    //是司机就应该会驾驶汽车
    public void drive();
    }
    public class Driver implements IDriver{
    private ICar car;
    //构造函数注入
    public Driver(ICar _car){
        this.car = _car;
    }
    //司机的主要职责就是驾驶汽车
    public void drive(){
        this.car.run();
    }
    }
  2. setter方法传递依赖对象
    public interface IDriver {
    //车辆型号
    public void setCar(ICar car);
    //是司机就应该会驾驶汽车
    public void drive();
    }
    public class Driver implements IDriver{
    private ICar car;
    public void setCar(ICar car){
        this.car = car;
    }
    //司机的主要职责就是驾驶汽车
    public void drive(){
        this.car.run();
    }
    }
  3. 接口声明依赖对象
    public interface IDriver {
    //在接口的方法中注入
    public void drive(ICar car);
    }

想要使用这个原则,遵循以下四点就够了:

  1. 每个类尽量提供接口或抽象类,或者两者都具备。
  2. 变量的声明类型尽量是接口或者是抽象类。
  3. 任何类都不应该从具体类派生。
  4. 使用继承时尽量遵循里氏替换原则。

接口隔离原则

Interface Segregation Principle(ISP原则)是2002 年罗伯特·C.马丁提出的,“客户端不应该被迫依赖于它不使用的方法”,或者说“一个类对另一个类的依赖应该建立在最小的接口上”。这要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口,让接口中只包含客户感兴趣的方法
接口隔离原则和单一职责都是为了提高类的内聚性、降低耦合性,体现了封装的思想,但两者是不同的:
单一职责原则注重的是职责,而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类,它针对的是程序中的实现和细节;接口隔离原则主要约束接口,主要针对抽象和程序整体框架的构建。
例子可以参考单一职责原则的例子(这两个原则真的很像)
遵循接口隔离原则时需要注意接口拆分粒度,如果定义过小,则会造成接口数量过多,使设计复杂化;如果定义太大,灵活性降低,无法提供定制服务,给整体项目带来无法预料的风险。
实现时遵循以下规则:

  1. 接口尽量小,但是要有限度。一个接口只服务于一个子模块或业务逻辑。
  2. 为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法。
  3. 了解环境,拒绝盲从。每个项目或产品都有选定的环境因素,环境不同,接口拆分的标准就不同深入了解业务逻辑。
  4. 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则

迪米特法则(Law of Demeter),又称最少知识原则(Least Knowledge Principle,LKP),产生于 1987 年美国东北大学的一个名为迪米特(Demeter)的研究项目,由伊恩·荷兰(Ian Holland)提出,被 UML 创始者之一的布奇(Booch)普及,后来又因为在经典著作《程序员修炼之道》(The Pragmatic Programmer)提及而广为人知。
定义:一个对象应该对其他对象有最少的了解;如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。
迪米特法则要求限制软件实体之间通信的宽度和深度,降低类之间的耦合,提高类的复用率和系统的扩展性。
使用时也需要注意使用程度,确保高内聚和低耦合的同时,保证系统的结构清晰。过度使用迪米特法则会使系统产生大量的中介类,从而增加系统的复杂性,使模块之间的通信效率降低。

实现时遵循以下规则:

  1. 在类的划分上,应该创建弱耦合的类。类与类之间的耦合越弱,就越有利于实现可复用的目标。
  2. 在类的结构设计上,尽量降低类成员的访问权限。
  3. 在类的设计上,优先考虑将一个类设置成不变类。
  4. 在对其他类的引用上,将引用其他对象的次数降到最低。
  5. 不暴露类的属性成员,而应该提供相应的访问器(set 和 get 方法)。
  6. 谨慎使用序列化(Serializable)功能。

举两个例子:
eg: 明星、代理人、媒体公司的关系:

体现定义:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。

eg: 软件类和安装类

优化前,Wizard把太多方法暴露给InstallSoftware类,一旦需要修改Wizard的first方法返回值,就需要修改InstallSoftware类,耦合较深。

优化后在Wizard类中增加一个installWizard方法,对安装过程进行封装,同时把原有的三个
public方法修改为private方法。通过这样的重构后,Wizard类就只对外公布了一个public方法,即使要修改具体步骤方法的返回值,影响的也仅仅只是Wizard本身,其他类不受影响,这显示了类的高内聚
特性。

开闭原则

Open Closed Principle,由勃兰特·梅耶(Bertrand Meyer)提出,他在 1988 年的著作《面向对象软件构造》(Object Oriented Software Construction)中提出:软件实体应当对扩展开放,对修改关闭(Software entities should be open for extension,but closed for modification),其含义是软件实体应该通过扩展来实现变化,而不是通过修改已有代码来实现。
开闭原则作用入下:

  1. 软件遵守开闭原则的话,软件测试时只需要对扩展的代码进行测试就可以了,因为原有的测试代码仍然能够正常运行。
  2. 可以提高代码的可复用性
  3. 可以提高软件的可维护性
    实现方法:
    可以通过抽象约束、封装变化来实现开闭原则,即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中,当软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以了。

参考

除了《设计模式之禅》外,这个网站给了极大帮助,讲解全面又简洁,看完这个感觉前书将的内容很细抓不住重点。
http://c.biancheng.net/view/1324.html

One thought on “设计模式之六大设计原则”

发表评论

电子邮件地址不会被公开。 必填项已用*标注