《转》面向对象类设计原则

面向对象类的设计原则

1                 SRP(单一职责原则)

这个原则看起来很简单,就是说一个类只能承担一个职责。

但这里有一个关键:“职责”是如何理解的?

按照汉语的理解,职责其实分为两部分:“职”和“责”。“职”就是这个类是什么,而“责”就是这个类要干什么。

举个例子来说:Door是一个对象,那么它的“职”就是门,“责”就是“开门、关门”等;而Lock的“职”就是锁,“责”就是“上锁、开锁”。如果设计的时候Door同时具有锁的职责,那么Door就违反了SRP原则。

2                 OCP(开闭原则)

相信这是大家见得最多的原则,而且很多人都是这么解释的“对扩展开放、对修改封闭”,更加有人总结为“不修改代码增加新的功能”!

太神奇了,不修改代码增加新的功能!但我不免疑惑:不修改代码怎么增加新的功能呢?难道代码会像生物一样,基因变异?

仔细研究过后才发现,原来是这些总结的人误导了我,根本不是什么“不修改代码增加新的功能”,也不是那个省略了主语的“对扩展开放,对修改封闭”,而是“被调用者开放扩展,调用者封闭修改”

还是举门的例子:Door对象是被其它对象例如人People调用,那么Door就是被调用者,People就是调用者。Door对象可以扩展为“防盗门”、“防火门”、“逃生门”等,但People在调用的时候不需要关注具体是什么门,只需要调用这些门公共的“开门、关门”等操作即可。

3                 LSP Liskov替换原则)

这个看起来是比较难理解的原则,但我可以给一个很容易理解的总结:“子类的输入不能比父类多,子类的输出不能比父类少!”。

“输入”就是指调用类的时候要给出的条件,最常见的就是函数参数,而一般的语言都可以从语法上保证这种子类和父类相同函数的参数必须相同;还有另外一种隐性的条件即“假设”或者“要求”也必须相同。

举个简单的例子:长方形和正方形。按照数学的定义,正方形是特殊的长方形。依照此定义看起来好像可以将正方形定义为长方形的子类,但实际上在面向对象设计中则是不行的,因为按照设定长方形长宽的方法不能来设定正方形的边长,正方形要求长宽必须相等,而长方形没有此“要求”。这就是子类的“假设”或者“假设”多于父类,违反了LSP原则。

“输出”就是指调用类后返回的结果。即:子类的返回结果要包含父类的返回结果,可以多但绝对不能少。

为什么设计时要满足LSP原则呢?其实很简单,因为调用者看到的只有父类,它根本不知道到底是哪个子类,调用者所有的处理都是基于父类提供给调用者的信息(包括输入信息和输出信息)。

4                 DIP(依赖反转原则)

这个原则看起来有点吓人,换个简单的说法你就明白了,其实它就对应于《设计模式》开头提到的两个原则中的一个:“基于接口编程,而不是基于实现编程”。(另外一个是什么呢?)

这里的“编程”包括“调用者”和“被调用者”的编程。“调用者”基于接口进行调用,“被调用者”基于接口进行具体实现。

注意:和“依赖反转”类似的两个比较容易混淆的概念是“依赖注入”和“控制反转”,详细可以参考如下博文:http://blog.csdn.net/taijianyu/archive/2008/04/28/2338311.aspx

5                 ISP(接口隔离原则)

这个原则也很简单,就是说一个对象不要提供多个接口,不同的接口应该分离到不同的对象上去。

虽然大师的水平不容怀疑,但这里我还是要怀疑一下:SRP和ISP本质上应该是一个原则,只是说法不一样而已。

为什么这么说呢?大家可以看看SRP原则,它说的是“单一职责”。那么职责最终体现在对象上是什么呢?对,不就是接口么!也就是说,如果遵循了SRP原则,接口自然就隔离了。

时间: 2024-10-24 13:35:09

《转》面向对象类设计原则的相关文章

面向对象的设计原则

面向对象设计原则是学习设计模式的基础,每一种设计模式都符合某一种或者多种面向对象设计原则.通过在软件开发中使用这些原则可以提高软件的可维护行和可用性,让我们可以设计出更加灵活也更加容易扩展的软件系统,实现可维护可复用的目标.在使用面向对象的思想进行系统设计时,前人共总结出了7条原则,它们分别是:单一职责原则.开闭原则.里氏替换原则.依赖注入原则.接口分离原则.迪米特原则和合成复用原则. 1.单一职责原则(SRP) 单一职责原则的核心思想就是:系统中的每一个对象都应该只有一个单独的职责,而所有对象

面向对象思想设计原则 及常见设计模式

1.面向对象思想设计原则 在实际的开发中,我们要想更深入的了解面向对象思想,就必须熟悉前人总结过的面向对象的思想的设计原则. 1)单一职责原则:就是开发人员经常说的”高内聚,低耦合”.也就是说,每个类应该只有一个职责,对外只能提供一种功能,而引起类变化的原因应该只有一个.在设计模式中,所有的设计模式都遵循这一原则. 2)开闭原则:一个对象对扩展开放,对修改关闭.也就是说,对类的改动是通过增加代码进行的,而不是修改现有代码.软件开发人员一旦写出了可以运行的代码,就不应该去改动它,而是要保证它能一直

零散知识点(面向对象七大设计原则,jdbc--BaseDao,jsp九大内置对象。四个作用域)

面向对象七大设计原则: 1.开闭原则(OCP:Open-Closed Principle)2.里氏替换原则(LSP:Liskov Substitution Principle) 3.单一职责原则(SRP:Single responsibility principle)4.接口隔离原则(ISP:Interface Segregation Principle)5.依赖倒置原则(DIP:Dependence Inversion Principle)6.迪米特法则(LOD:Law of Demeter)

java 28 - 1 设计模式 之 面向对象思想设计原则和模版设计模式概述

在之前的java 23 中,了解过设计模式的单例模式和工厂模式.在这里,介绍下设计模式 面向对象思想设计原则 在实际的开发中,我们要想更深入的了解面向对象思想,就必须熟悉前人总结过的面向对象的思想的设计原则 单一职责原则 开闭原则 里氏替换原则 依赖注入原则 接口分离原则 迪米特原则 单一职责原则 其实就是开发人员经常说的"高内聚,低耦合" 也就是说,每个类应该只有一个职责,对外只能提供一种功能,而引起类变化的原因应该只有一个.在设计模式中,所有的设计模式都遵循这一原则. 开闭原则 核

Java 面向对象的设计原则

一. 1.面向对象思想的核心: 封装.继承.多态.   2.面向对象编程的追求: 高内聚低耦合的解决方案: 代码的模块化设计: 3.什么是设计模式: 针对反复出现的问题的经典解决方案,是对特定条件下(上下文)问题的设计方案的经验总结,是前人设计实践经验的精华. 4.面向对象设计原则 是面向对象设计思想(法理精神)的提炼(基本宪法),比面向对象思想的核心要素更具有实操性,比设计模式(各种具体法律条文)更抽象. 5.如何最大限度降低耦合度? 少用类的继承,多用接口隐藏实现细节. 避免使用全局变量.

GOF 的23种JAVA常用设计模式总结 03 面向对象七大设计原则

在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据 7 条原则来开发程序,从而提高软件开发效率.节约软件开发成本和维护成本. 各位代码界的大佬们总结出的七大设计原则,还是需要好好了解一下 1.开闭原则 开闭原则(Open Closed Principle,OCP)由勃兰特·梅耶(Bertrand Meyer)提出,他在 1988 年的著作<面向对象软件构造>(Object Oriented Software Construction)中提出:软件实

第2章 面向对象的设计原则(SOLID):3_依赖倒置原则

3. 依赖倒置原则(Dependence Inversion Principle,DIP) 3.1 定义 (1)要依赖抽象,不要依赖具体的实现类.简单的说就是对抽象(或接口)进行编程,不要依赖实现进行编程,这样就降低了客户与实现模块间的耦合.包含3层含义: ①高层模块不应依赖低层模块,两者都应该依赖于抽象 ②抽象不应该依赖细节 ③细节应该依赖于抽象 (2)何为“高层模块”和“低层模块” ①“低层模块”:每个逻辑的实现都是原子逻辑组成,不可分割的原子逻辑就是低层模块.一般和具体实现相关. ②“高层

.NET 高级架构师0005 架构师之路(4)---面向对象的设计原则

1         OO的设计原则 采用面向对象的分析和设计思想,为我们分析和解决问题提供了一种全新的思维方式.我们在拿到需求之后(略去OOA,以后补全),接下来的问题就是:如何对系统进行面向对象的设计呢? 按照软件工程的理论,面向对象的设计要解决的核心问题就是可维护性和可复用性.尤其是可维护性,它是影响软件生命周期重要因素,通常情况下,软件的维护成本远远大于初期开发成本. 一个可维护性很差的软件设计,人们通常称之为"臭味"的,形成的原因主要有这么几个:过于僵硬.过于脆弱.复用率低或者

【设计模式】 面向对象六大设计原则

面向对象设计的六大原则 : 单一职责原则, 里氏替换原则, 依赖倒置原则, 接口隔离原则, 迪米特法则, 开闭原则; 一. 单一职责原则 1. 单一职责简介 单一职责定义 : 有且只有一个原因引起类的变化, 一个接口 或者 类 只有一个职责; 单一职责的好处 : -- 复杂性 : 降低类的复杂性, 对类或接口的职责有清晰明确定义; -- 可读性 : 提高可读性; -- 维护 : 提高可维护性; -- 变更风险 : 降低变更引起的风险, 接口改变只影响相应的实现类, 不影响其他类; 2. 单一职责