java设计模式:面向对象设计的7个原则

在软件开发中,为了提升软件系统的可维护性和可复用性,增长软件的可扩展性和灵活性,程序员要尽可能根据7条原则来开发程序,从而提升软件开发效率,节约软件开发成本和维护成本。程序员

这7条原则分别是:开闭原则里氏替换原则依赖倒置原则单一职责原则接口隔离原则迪米特法则合成复用原则编程

接下来是对这7个原则的详细介绍。设计模式

开闭原则(OCP,Open Closed Principle)架构

定义框架

开闭原则(Open Closed Principle,OCP)由勃兰特·梅耶(Bertrand Meyer)提出,他在 1988 年的著做《面向对象软件构造》(Object Oriented Software Construction)中提出:软件实体应当对扩展开放,对修改关闭(Software entities should be open for extension,but closed for modification),这就是开闭原则的经典定义。测试

当应用的需求发生改变时,在不修改软件实体的源代码或者二进制代码的前提下,能够扩展模块的功能,使其知足新的需求。spa

这里的软件实体包含几个部分:项目中划分出的模块、类和接口、方法。设计

做用对象

开闭原则是面向对象程序设计的终极目标,它使软件实体拥有必定的适用性和灵活性的同时具有稳定性和延续性。继承

对软件测试的影响

软件遵循开闭原则的话,软件测试时只须要对扩展的代码进行测试就能够了,由于原有的测试代码依然可以正常运行。

能够提升代码的可复用性

粒度越小,被服用的可能性就越大;在面向对象的程序设计中,根据原则和抽象编程能够提升代码的可复用性。

能够提升软件的可维护性

遵照开闭原则的软件,其稳定性高和延续性强,从而易于扩展和维护。

实现方法

能够经过【抽象约束、封装变化】来实现开闭原则,即经过接口或抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中。

由于抽象灵活性好,适应性广,只要抽象得合理,能够基本保持软件架构的稳定,而软件中易变的细节能够从抽象派生来的实现类来进行扩展,当软件须要发生变化的时候,只须要根据需求从新派生一个实现类来扩展就能够了。

里氏替换原则(LSP,Liskov Subsititution Principle)

定义

里氏替换原则(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)。

里氏替换原则主要阐述了有关继承的一些原则,也就是何时应该使用继承,何时不该该使用继承,以及其中蕴含的原理。里氏替换原则是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。

做用

里氏替换原则是实现开闭原则的重要方式之一。

里氏替换原则克服了继承中重写父类形成的可复用性变差的缺点。

里氏替换原则是动做正确性的保证。即类的扩展不会给已有的系统引入新的错误,下降了代码出错的可能性。

实现方法

里氏替换原则通俗地来说就是:子类能够扩展父类的功能,但不能改变父类原有的功能。也就是说,子类继承父类时,除了添加新的方法完成新增功能外,尽可能不要重写父类的方法。

若是经过重写父类的方法来完成新的功能,这样写起来虽然简单,可是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的几率会很是大。

若是程序违背了里氏替换原则,则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是:取消原来的继承关系,从新设计它们之间的关系。

关于里氏替换原则的例子,最有名的是【正方形不是长方形】。固然,生活中也有不少相似的例子,例如,企鹅、鸵鸟和几维鸟从生物学的角度来划分,它们属于鸟类,可是从类的继承关系来看,因为它们不能继承鸟类会飞的功能,因此它们不能定义成鸟类的子类。一样的,因为气球鱼不会游泳,也不可以被定义成会游泳的鱼类的子类。

依赖倒置原则(DIP,Dependence Inversion Principle)

定义

依赖倒置原则(Dependence Inversion Principle,DIP)是 Object Mentor 公司总裁罗伯特·马丁(Robert C.Martin)于 1996 年在 C++ Report 上发表的文章。

依赖倒置原则的原始定义为:高层模块不该该依赖低层模块,二者都应该依赖其抽象;抽象不该该依赖细节,细节应该依赖抽象(High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions)。其核心思想是:要面向接口编程,不要面向实现编程。

依赖倒置原则是实现开闭原则的重要途径之一,它下降了客户与实现模块之间的耦合。

因为在软件设计中,细节具备多变性,而抽象层则相对稳定,所以以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或抽象类,而细节则是指具体的实现类。

使用接口或抽象类的目的是制定好规范和契约,而不去涉及任何具体的操做,把展示细节的任务交给它们的实现类去完成。

做用

依赖倒置原则能够下降类间的耦合性。

依赖倒置原则能够提升系统的稳定性。

依赖倒置原则能够减小并行开发引发的风险。

依赖倒置原则能够提升代码的可读性和可维护性。

实现方法

依赖倒置原则的目的是经过要面向接口的编程来下降类间的耦合性,因此咱们在实际编程中只要遵行如下4点,就能在项目中知足这个规则。

每一个类尽可能提供接口或抽象类,或者二者都具有。

变量的声明类型尽可能是接口或抽象类。

任何类都不该该从具体类派生。

使用继承时尽可能遵循里氏替换原则。

单一职责原则(SRP,Single Responsibility Principle)

定义

单一职责原则(Single Responsibility Principle,SRP)又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中提出的。这里的职责是指类变化的缘由,单一职责原则规定一个类应该有且仅有一个引发它变化的缘由,不然类应该被拆分(There should never be more than one reason for a class to change)。

该原则提出,对象不该该承担太多职责,若是一个对象承担了太多的职责,至少存在如下两个缺点:

一个职责的变化可能会削弱或者抑制这个类实现其余职责的能力;

当客户端须要该对象的某一职责时,不得不将其余不须要的职责全都包含进来,从而形成荣冗余代码或代码的浪费。

优势

单一职责的核心就是控制类的粒度大小,将对象解耦,提升其内聚性。若是遵循单一职责原则将会由如下优势:

下降类的可读性

一个类只负责一项职责,其逻辑确定要比负责多项职责简单得多。

提升类的可读性

复杂性下降,天然其可读性会提升。

提升系统的可维护性

可读性提升,天然是更容易维护了。

下降变动引发的风险

变动几乎是必然的,若是单一职责原则遵照得好,当修改一个功能时,能够显著下降对其余功能得影响。

实现方法

单一职责原则是最简单但又是最难运用的原则,须要设计人员发现类的不一样职责并将其分离,再封装到不一样的类或模块中。而发现类的多重职责须要设计人员具备较强的分析设计能力和相关重构经验。

单一职责原则一样也适用于方法。一个方法应该尽量作好一件事情。若是一个方法处理的事情太多,其颗粒度会变得很粗,不利于重用。

接口隔离原则(ISP,Interface Segregation Principle)

定义

接口隔离原则(Interface Segregation Principle,ISP)要求程序员尽可能将臃肿庞大的接口拆分红更小的和更具体的接口,让接口中只包含客户感兴趣的方法。

2002 年罗伯特·C.马丁给“接口隔离原则”的定义是:客户端不该该被迫依赖于它不使用的方法(Clients should not be forced to depend on methods they do not use)。该原则还有另一个定义:一个类对另外一个类的依赖应该创建在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)。

以上两个定义的含义是:要为各个类创建它们须要的专用接口,而不要试图去创建一个很庞大的接口供全部依赖它的类去调用。

接口隔离原则和单一职责原则都是为了提升类的内聚性,下降它们之间的耦合性,体现了封装的思想,但二者是不一样的,不一样在于:

单一职责原则注重的是职责,而接口隔离原则注重的是对接口依赖的隔离;

单一职责原则主要是约束类,它针对的是程序中的实现和细节;接口隔离原则主要是约束接口,针对抽象和程序总体框架的构建。

优势

接口隔离原则是为了约束接口,下降类对接口的依赖性,遵循接口隔离原则有如下5个优势。

将臃肿庞大的接口分解为多个粒度小的接口,能够预防外来变动的扩散,提升系统的灵活性和可维护性。

提升了系统的内聚性,减小了对外交互,下降了系统的耦合性。

若是接口的粒度大小定义合理,可以保证系统的稳定性;可是,若是定义太小,则会形成接口数量过多,使设计复杂化;若是定义太大,灵活性下降,没法提供定制服务,给总体项目带来没法预料的风险。

使用多个专门的接口可以体现对象的层次,由于能够经过接口的继承实现对总接口的定义。

能减小项目工程中的代码冗余。过大的大接口里面一般会防止许多用不到的方法,当实现这个接口的时候,会被迫去添加冗余的代码。

实现方法

在具体应用接口隔离原则时,应该根据如下几个规则来衡量。

接口尽可能小,可是要有限度。一个接口只服务于一个子模块或业务逻辑。

为依赖接口的类定制服务。只提供调用者须要的方法,屏蔽不须要的方法。

了解环境,拒绝盲从。每一个项目或产品都有选定的环境因素。环境不一样,接口拆分的标准就不一样。拆分接口的时候要深刻了解业务逻辑。

提升内聚,减小对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则(LoD,Law of Demeter)

定义

迪米特法则(Law of Demeter,LoD)又叫做最少知识原则(Least Knowledge Principle,LKP),产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目,由伊恩·荷兰(Ian Holland)提出,被 UML 创始者之一的布奇(Booch)普及,后来又由于在经典著做《程序员修炼之道》(The Pragmatic Programmer)说起而广为人知。

迪米特法则的定义是:只与你的直接朋友交谈,不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)。其含义是:若是两个软件实体无须直接通讯,那么就不该当发生直接的相互调用,能够经过第三方转发该调用。其目的是下降类之间的耦合度,提升模块的相对独立性。

迪米特法则中的【朋友】是指:当前对象自己、当前对象的成员对象、当前对象所建立的对象、当前对象的方法参数等。这些对象同当前对象存在关联、聚合或组合关系,能够直接访问这些对象的方法。

优势

迪米特法则要求限制软件实体之间通讯的宽度和深度,正确使用迪米特法则,有两个优势:

下降类之间的耦合度,提升模块的相对独立性。

因为耦合度下降,从而提升类的可复用率和系统的扩展性。

可是,过分使用迪米特法则,会使系统产生大量的中介类,致使系统的复杂度增长和模块之间的通讯效率下降。因此在使用迪米特法则的时候每每须要反复权衡,以确保在高内聚低耦合的同时,可以保证系统的结构清晰。

实现方法

从迪米特法则的定义和特色可知,它强调如下2点:

从依赖者的角度来讲,只依赖应该依赖的对象。

从被依赖者的角度说,只暴露应该暴露的方法。

因此,在运用迪米特法则时要注意如下6点:

在类的划分上,应该建立弱耦合的类。类与类之间的耦合越弱,就越有利于实现可复用的目标。

在类的结构设计上,尽可能下降类成员的访问权限。

在类的设计上,优先考虑将一个类设置成不变类。

在对其余类的引用上,将引用其余对象的次数降到最低。

谨慎使用序列化(Serializable)功能。

合成复用原则(CRP,Composite Reuse Principle)

定义

合成复用原则(Composite Reuse Principle,CRP)又叫组合/聚合复用原则(Composition/Aggregate Reuse Principle,CARP)。它要求在软件复用时,要尽可能先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。

若是要使用继承关系,则必须严格遵循里氏替换原则。合成复用原则是和里氏替换原则相辅相成的,二者都是开闭原则的具体实现规范。

优势

一般类的复用分为继承复用和合成复用两种,继承复用虽然有简单和易实现的优势,可是它也存在如下缺点:

继承复用破坏了类的封装性。由于继承会将父类的实现细节暴露给子类,父类对子类是透明的,因此这种复用又被称为【白箱复用】。

子类与父类的耦合度高。父类的实现的任何改变都会致使子类的实现发生变化,这不利于类的扩展与维护。

限制了复用的灵活性。从父类继承而来的实现是静态的,在编译时已经定义,因此在运行时不可能发生变化。

采用组合或聚合复用时,能够将已有对象归入新对象中,使之成为新对象的一部分,新对象能够调用已有对象的功能,具备如下优势:

维持类的封装性。由于成分对象的内部细节是新对象看不见的,多以这种复用又被称为【黑箱复用】。

新旧类之间的耦合度低。这种复用所须要的依赖较少,新对象存取成分对象的惟一方法是经过成分对象的接口。

复用的灵活性高。这种复用能够在运行时动态进行,新对象能够动态地引用与成分对象类型相同的对象。

实现方法

合成复用原则是经过将已有的对象归入新对象中,做为新对象的成员对象来实现的,新对象能够调用已有对象的功能,从而达到复用的目的。

 

上述的7个设计原则,是软件设计模式必须遵循的原则。各个原则要求的侧重点不一样。其中,开闭原则是总纲,它告诉咱们要对扩展开放,对修改关闭;里氏替换原则告诉咱们不要破坏继承体系;依赖倒置原则告诉咱们要面向接口编程;单一职责原则告诉咱们实现类要职责单一;接口隔离原则告诉咱们在设计接口的时候要精简单一;迪米特法则告诉咱们要下降耦合度;合成复合原则告诉咱们要优先使用组合或者聚合关系复用,少用继承关系复用。

相关文章
相关标签/搜索