【小话设计模式】面向对象设计原则

1.单一职责原则

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

单一职责原则——》“高内聚,低耦合”,每个类应该只有一个职责,此外只能提供一种功能,而引起类变化的原因应该只有一个。在设计模式中,所有的设计模式都遵循这一原则。

优点:

可以降低类的复杂度;

提高类的可读性,提高系统的可维护性;

变更引起的风险降低。

2.里氏替换原则

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

里氏替换原则——》同一个继承体系中的对象应该有共同的行为特征 。

在里氏替换原则中,所有引用基类的地方必须能够透明地使用其子类对象 。也就是,只要父类出现的地方,子类就能够出现,而且替换为子类不会产生任何错误或异常。反过来,子类出现的地方,替换为父类就可能出现问题。

有4层含义:

(1)子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。

(2)子类可以有自己的特性 。也就是说在类的子类上,可以定义其他的方法或属性。

(3)覆盖或者实现父类的方法时输入参数可以被放大,反之则不行

(4)当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

子类可以扩展父类的功能,但不能改变父类原有的功能。

3.依赖注入原则

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

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

依赖注入原则有如下三点说明:

1.高层模块不应该依赖底层模块,两者都应该依赖于抽象(抽象类或接口)

2.抽象(抽象类或接口)不应该依赖于细节(具体实现类)。

3.细节(具体实现类)应该依赖抽象。

依赖注入原则的本质是通过抽象(抽象类或接口)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合。这个原则是6个原则中最难实现的了,若果没有实现这个原则,也就意味着开闭原则(对扩展开放,对修改关闭)也无法实现。

依赖注入原则用如下三种方式实现。

(1)通过构造函数传递依赖对象

例如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

(2)通过setter方法传递依赖对象。

即在我们设置的setXXX方法中的参数为抽象类或接口,来实现传递依赖对象

(3)接口声明实现依赖对象

4.接口分离原则

接口分离原则核心思想就是:不应该强迫客户程序依赖它们不需要使用的方法。

英文缩写ISP,Interface Segregation Principle。

接口分离原则——》一个接口不需要提供太多的行为,一个接口应该只提供一种对外的功能,不应该把所有的操作都封装到一个接口中。

接口分两种:

(1)对象接口

Java中声明的一个类,通过new关键字产生的一个实例,它是对一个类型的事务的描述,这也是一种接口。

(2)类接口

这种接口是通过关键字interface定义的接口。

接口分离原则要求的是在一个模块中应该只依赖它需要的接口,以保证接口的小纯洁。而且需要保证接口应该尽量小,即设计接口的时候让接口尽量细化,不要定义太臃肿的接口。

单一职责原则要求的是类和接口职责单一,注重的是职责,是业务逻辑上的划分。而接口分离原则要求的是接口的方法尽量少,针对一个模块尽量有用。

接口分离原则的规范:

(1)接口尽量小:主要是为了保证一个接口只服务于一个子模块或者业务逻辑。

(2)接口高内聚:接口高内聚是对内高度依赖,对外尽可能隔离。即一个接口内部声明的方法相互之间都与某一个子模块相关,且是这个子模块必需的。

(3)接口设计是有限度的:如果完全遵循接口分离原则的话,会出现一个问题,即接口的设计力度越来越小,这样就造成了接口数据剧增,系统复杂度一下子增加了,而这不是真实项目所需要的,所以在使用这个原则的时候,还要在特定的项目中,根据经验或者尝试去判断,但没有一个固定的标准。

5.迪米特原则

迪米特原则LOD  Law of Demeter.

迪米特原则的核心思想就是:一个对象应当对其他对象尽可能少地了解。意思就是降低各个对象之间的耦合,提高系统的可维护性。迪米特法则又叫最少知道原则。在模块之 间,应该只通过接口通信,而不理会模块的内部工作原理,它可以使各个模块耦合程度降到最低,促进软件的复用。

迪米特原则的核心观念就是类间解耦,弱耦合。只有弱耦合了以后,类的复用性才可以提高。

在应用迪米特法则时的注意事项如下:

1.在类划分上,应该创建有弱耦合的类。

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

3.在类的设计上,只要有可能,一个类应当设计成不变的类。

4.在对其他类的引用上,一个对对象对其他对象的引用应当降到最低。

5.尽量降低类的访问权限。

6.谨慎使用序列化功能。

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

6.开闭原则

开闭原则缩写OCP  Open for Extension,Closed for Modification

开闭原则的核心思想是:一个对象对扩展开放,对修改关闭。

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

根据开闭原则,改变软件时,应通过扩展的方式来实现软件的改变,而不应靠修改原有代码来实现变化。

开闭原则是前5种原则的一个抽象总结,前5种是开闭原则的一些具体实现。

【小话设计模式】面向对象设计原则,布布扣,bubuko.com

时间: 2024-10-07 06:28:30

【小话设计模式】面向对象设计原则的相关文章

设计模式-面向对象设计原则

七种常用的面向对象设计原则 单一职责原则(Single Responsibility Principle,SRP): 一个类只负责一个功能领域中的相应职责. 开闭原则(Open-Close Principle,OCP): 软件实体应对外扩展开放,而对修改关闭. 里氏代换原则(Liskov Substitution Principle,LSP): 所有引用基类对象的地方能够透明的使用其子类的对象. 依赖倒换原则(Dependence Inversion Principle,DIP): 抽样不应该依

设计模式——面向对象设计原则

设计原则名称 设计原则简介 重要性 单一职责原则 类的职责要单,不能将太多的职责放在一个类中 四颗星 开闭原则 软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件实体的基础上去扩展其功能 五颗星 里氏替换原则 在软件系统中一个可以接受基类对象的地方必然可以接受一个子类对象 四颗星 依赖倒转原则 要针对抽象层编程,而不要针对具体类编程 五颗星 接口隔离原则 使用多个专门的接口来取代一个统一的接口 两颗星 迪米特法则 一个软件实体对其它实体的引用越少越好,或者说如果两个类不必彼此直接通信,

小话设计模式之设计心得

经常看到各个论坛经常有人讨论设计模式,进去一看,基本都是造搬一些设计模式书上的例子.看完之后,往往有一个疑问,他们写完之后在实际工作到底能不能用上呢? 今天闲着无聊,说说自己工作上使用过的心得.欢迎拍砖! 首先,设计模式到底是什么东西? (本来想留最后写,写完发现不知道怎么写了,就不写了) 使用设计模式到底为了什么? (本来想留最后写,写完发现不知道怎么写了,就不写了) 怎么把设计模式应用到工作中去? 这个我觉得最重要的,犹想当年刚开始学习设计模式时,把一本几百页的书看完,里面提到的30左右个设

C#软件设计——小话设计模式原则之:开闭原则OCP

前言:这篇继续来看看开闭原则.废话少说,直接入正题. 软件设计原则系列文章索引 C#软件设计——小话设计模式原则之:依赖倒置原则DIP C#软件设计——小话设计模式原则之:单一职责原则SRP C#软件设计——小话设计模式原则之:接口隔离原则ISP C#软件设计——小话设计模式原则之:开闭原则OCP 一.原理介绍 1.官方定义 开闭原则,英文缩写OCP,全称Open Closed Principle. 原始定义:Software entities (classes, modules, functi

C#软件设计——小话设计模式原则之:依赖倒置原则DIP

前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”,即各方便都有战斗力.关于设计模式,作为程序猿的我们肯定都不陌生.博主的理解,所谓设计模式就是前人总结下来的一些对于某些特定使用场景非常适用的优秀的设计思路,“前人栽树,后人乘凉”,作为后来者的我们就有福了,当我们遇到类似的应用场景的时候就可以直接使用了.关于设计模式的原则,博主将会在接下来的几篇里面

UML类图与面向对象设计原则—设计模式01

1. 引言     从大一开始学习编程,到如今也已经有两年了.从最初学习的Html,Js,JaveSe,再到JavaEE,Android,自己也能写一些玩具.学习过程中也无意识的了解了一些所谓的设计模式,如今打算系统的学习.学习以书<设计模式的艺术--软件开发人员内功修炼之道/刘伟著>为主.       所谓设计模式,即是前人对某类相似问题的抽象给出的解决方案.书中给出了23(Gof)+1(简单工厂模式)种设计模式.每种模式的学习将关注以下几点:名称(Name),问题(Problem),解决方

设计模式2 面向对象设计原则

面向对象设计原则  原则的目的 面向对象设计原创表  单一职责原则案例 开闭原则 案例 依赖倒转原则 案例 面向对象设计原则  对于面向对象软件系统的设计而言,在支持可维护性的同时,提高系统的可复用性是一个至关重要的问题,如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一.在面向对象设计中,可维护性的复用是以设计原则为基础的.每一个原则都蕴含一些面向对象设计的思想,可以从不同的角度提升一个软件结构的设计水平.  面向对象设计原则为支持可维护性复用而诞生,这些原则蕴含

面向对象设计原则,设计模式

面向对象设计原则之一:单一职责原则 面向对象设计原则之二:开放封闭原则 面向对象设计原则之三:里氏替换原则 面向对象设计原则之四:依赖倒置原则 面向对象设计原则之五:迪米特法则 Java之美[从菜鸟到高手演变]之设计模式 Java之美[从菜鸟到高手演变]之设计模式二

C++ 设计模式2 (面向对象设计原则)

1. 变化是复用的天敌! 面向对象设计的最大优势在于 : 抵御变化 2. 重新认识面向对象 理解隔离变化: 从宏观层面来看,面向对象的构建方式更能适应软件的变化, 能将变化所带来的影响减为最小. 各司其职: 从微观层面来看,面向对象的方式更强调各个类的”责任“ (代码示例中,各个类型图形,各自实现自己的draw) 由于需求变化导致的新增类型不应该影响原来类型的实现 ——各负其责. 对象是什么? 从语言实现的层面,对象是封装了代码和数据. 从规格层面讲,对象是一系列可被使用的公共接口. 从概念层面