面向对象的七大设计原则

七大原则总脉络图:

常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充。

 原则一 开闭原则(OCP) 

 OCP简单来说就是 对扩展是开放的,对修改是封闭的。

开闭原则的核心思想就是:一个对象对扩展开放,对修改关闭。它的英文缩写是OCP,英文全称是Open for Extension,Closed for Modification。 

其实开闭原则的意思就是:对类的改动是通过增加代码进行的,而不是改动现有的代码。也就是说,软件开发人员一旦写出了可以运行的代码,就不应该去改变它,而是要保证它能一直运行下去,如何才能做到这一点呢?这就需要借助于抽象和多态,即把可能变化的内容抽象出来,从而使抽象的部分是相对稳定的,而具体的实现层则是可以改变和扩展的。 

扩展开放:某模块的功能是可扩展的,则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。

修改关闭:某模块被其他模块调用,如果该模块的源代码不允许修改,则该模块修改关闭的。软件系统的功能上的稳定性,持续性要求是修改关闭的

 原则二  (DIP)依赖倒转原则

依赖注入原则的核心思想就是:要依赖于抽象,不要依赖于具体的实现。它的英文缩写是DIP,英文全称是Dependence Inversion Principle。

其实依赖注入原则的意思就是:在应用程序中,所有的类如果使用或依赖于其他的类,则都应该依赖于这些其他类的抽象类,而不是这些其他类的具体实现类。抽象层次应该不依赖于具体的实现细节,这样才能保证系统的可复用性和可维护性。为了实现这一原则,就要求开发人员在编程时要针对接口编程,而不针对实现编程。 

依赖注入解除了对象和对象的依赖关系,需要其他对象,会有外部直接注入,而你自己不需要关心他如何而来。对象符合OCP原则(对外扩展开放,对修改关闭), 容器负责所有关系匹配。在此层,容器便是这个社会的规则,而对象只需要关心自己所完成的一部分。

三种实现方式:

 1、通过构造函数传递依赖对象;2、通过setter方法传递依赖对象 ;3、接口声明实现依赖对象

在Java中的表现:

(1)模块间的依赖是通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;

(2)接口或抽象类不依赖于实现类;

(3)实现类依赖接口或抽象类。

原则三 里氏代换原则(LSP)

里氏替换原则的核心思想就是:在任何父类出现的地方都可以用它的子类来替代。它的英文缩写是LSP,英文全称是Liskov Substitution Principle

其实里氏替换原则的意思就是:同一个继承体系中的对象应该有共同的行为特征。里氏代换原则关注的是怎样良好地使用继承,也就是说不要滥用继承,它是继承复用的基石。

四层含义:

(1)子类必须完全实现父类的方法。在类中调用其他类是务必要使用父类或接口,如果不能使用父类或接口,则说明类的设计已经违背了LSP原则。

(2)子类可以有自己的个性。子类当然可以有自己的行为和外观了,也就是方法和属性

(3)覆盖或实现父类的方法时输入参数可以被放大。即子类可以重载父类的方法,但输入参数应比父类方法中的大,这样在子类代替父类的时候,调用的仍然是父类的方法。即以子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松。

(4)覆盖或实现父类的方法时输出结果可以被缩小。

      LSP俗语是:“老鼠的儿子会打洞。”,其实就是子类是和父类有相同的行为和状态,是可以完全替换父类的。这也是保护了OCP的开放扩展关闭修改的原则。

原则四   单一职责原则(SRP)

单一职责原则的核心思想就是:系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成。它的英文缩写是SRP,英文全称是Single Responsibility Principle。

核心:解耦和增强内聚性(高内聚,低耦合)。

描述:类被修改的几率很大,因此应该专注于单一的功能。

如果你把多个功能放在同一个类中,功能之间就形成了关联,改变其中一个功能,有可能中止另一个功能,这时就需要新一轮的测试来避免可能出现的问题。

简而言之,SRP就是指单个类应该有且仅有单个职能。

原则五   接口分离原则(接口隔离原则 ISP)

接口分离原则的核心思想就是:不应该强迫客户程序依赖它们不需要使用的方法。它的英文缩写是ISP,英文全称是Interface Segregation Principle。

其实接口分离原则的意思就是:一个接口不需要提供太多的行为,一个接口应该只提供一种对外的功能,不应该把所有的操作都封装到一个接口当中。  

接口隔离原则的定义

第一种定义:客户端不应该依赖它不需用的接口。

第二种定义:一个类对另外一个类的依赖性应当是建立在最小的接口上的。

接口分以下两种:

对象接口(Object Interface)Java中声明的一个类,通过new关键字产生的一个实例,对一个类型事物的描述,也是一种接口。

类接口(Class Interface)通过关键字Interface定义的接口。

分离接口的两种实现方法:

(1)使用委托分离接口。(Separation through Delegation)

就把请求委托给别的接口的实现类来完成需要的职责,就是适配器模式(Adapter)。

(2)使用多重继承分离接口。(Separation through Multiple Inheritance。)

该方法通过实现多个接口来完成需要的职责。

两种方式各有优缺点,通常我们应该先考虑后一个方案,如果涉及到类型转换时则选择前一个方案。

原则六  合成(聚合)复用原则(CARP)

合成复用原则的核心思想就是:优先使用组合,而不是继承。它的英文缩写是CARP,英文全称是Composite/Aggregate Reuse Principle。 

合成复用原则的意思就是:在复用对象的时候,要优先考虑使用组合,而不是继承,这是因为在使用继承时,父类的任何改变都可能影响子类的行为,而在使用组合时,是通过获得对其他对象的引用而在运行时刻动态定义的,有助于保持每个类的单一职责原则。 

术语:

(1)聚合(Aggregation):聚合用来表示“拥有”关系或者整体与部分的关系;

(2)合成(Composition):合成则用来表示一种强得多的“拥有”关系。在一个合成关系里面,部分和整体的生命周期是一样的。

复用的种类:

(1)继承

  ① 优点:

新的实现较为容易,因为基类的大部分功能可以通过继承关系自动进入派生类;

修改或扩展继承而来的实现较为容易。

  ② 缺点:

继承复用破坏包装,因为继承将基类的实现细节暴露给派生类,这种复用也称为白箱复用;

如果基类的实现发生改变,那么派生类的实现也不得不发生改变;

从基类继承而来的实现是静态的,不可能在运行时发生改变,不够灵活。

(2)合成聚合

  ① 优点:

新对象存取成分对象的唯一方法是通过成分对象的接口;

这种复用是黑箱复用,因为成分对象的内部细节是新对象所看不见的;

这种复用支持包装;

这种复用所需的依赖较少;

每一个新的类可以将焦点集中在一个任务上;

这种复用可以在运行时动态进行,新对象可以使用合成/聚合关系将新的责任委派到合适的对象。

  ② 缺点:

通过这种方式复用建造的系统会有较多的对象需要管理。

在复用时应优先考虑使用合成聚合而不是继承,而判定的判断为以下四个Coad条件:

  ① 派生类是基类的一个特殊种类,而不是基类的一个角色,即要分清"Has-A"和"Is-A"的区别;

  ② 永远不会出现需要将派生类换成另一个类的派生类的情况;

  ③ 派生类具有扩展基类的责任,而不是具有置换或者注销掉基类的责任;

  ④ 只有在分类学角度有意义时,才可以使用继承。

原则七  迪米特法则(LOD)

迪米特原则的核心思想就是:一个对象应当对其他对象尽可能少的了解。它的英文缩写是LOD,英文全称是Law of Demeter。 

其实迪米特原则的意思就是:降低各个对象之间的耦合,提高系统的可维护性。在模块之间,应该只通过接口来通信,而不理会模块的内部工作原理,它可以使各个模块耦合程度降到最低,促进软件的复用。

在将迪米特法则运用到系统的设计中时,应注意的几点:

① 在类的划分上,应该创建有弱耦合的类;

② 在类的结构设计上,每一个类都应当尽量降低成员的访问权限;

③ 在类的设计上,只要有可能,一个类应当设计成不变类;

④ 在对其他类的引用上,一个对象对其它对象的引用应当降到最低;

⑤ 尽量降低类的访问权限;

⑥ 谨慎使用序列化功能;

优点:

<1>迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系。

<2>遵循迪米特法则会使一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有直接关联

缺点:

<1>会在系统里造出大量的小方法,散落在系统的各个角落。这些方法仅仅是传递间接的调用,因此与系统的商务逻辑无关,当设计师试图从一张类图看出总体的框架时,这些小的方法会造成迷惑和困扰。

<2>会造成系统的不同模块之间的通信效率降低,也会使系统的不同模块之间不容易协调。

设计模式中的应用:

<1>门面模式(Facade Pattern)

<2>中介模式(Mediator Pattern)

⑦ 不要暴露类成员,而应该提供相应的访问器(属性)

原文地址:https://www.cnblogs.com/luoxionghenku/p/8283294.html