OO六大设计原则

什么是设计原则?
设计原则是基本的工具,应用这些规则可以使你的代码更加灵活、更容易维护,更容易扩展。

基本原则

封装变化
面向接口编程而不是实现 
优先使用组合而非继承
SRP: The single responsibility principle 单一职责
系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成。只能让一个类有且仅有一个职责。

每一个职责都是一个设计的变因,需求变化的时候,需求变化反映为类职责的变化。当你系统里面的对象都只有一个变化的原因的时候,你就已经很好的遵循了SRP原则。
如果一个类承担的职责过多,就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候,设计会遭到意想不到的破坏。
SRP 让这个系统更容易管理维护,因为不是所有的问题都搅在一起。
内聚Cohesion 其实是SRP原则的另外一个名字.你写了高内聚的软件其实就是说你很好的应用了SRP原则。
怎么判断一个职责是不是一个对象的呢?你试着让这个对象自己来完成这个职责,比如:“书自己阅读内容”,阅读的职责显然不是书自己的。
仅当变化发生时,变化的轴线才具有实际的意义,如果没有征兆,那么应用SRP或者任何其它的原则都是不明智的。
DRY : Don‘t repeat yourself Principle
通过抽取公共部分放置在一个地方避免代码重复.

DRY 很简单,但却是确保我们代码容易维护和复用的关键。
你尽力避免重复代码候实际上在做一件什么事情呢?是在确保每一个需求和功能在你的系统中只实现一次,否则就存在浪费!系统用例不存在交集,所以我们的代码更不应该重复,从这个角度看DRY可就不只是在说代码了。
DRY 关注的是系统内的信息和行为都放在一个单一的,明显的位置。就像你可以猜到正则表达式在.net中的位置一样,因为合理所以可以猜到。
DRY 原则:如何对系统职能进行良好的分割!职责清晰的界限一定程度上保证了代码的单一性。
OCP : Open-Close Principle开闭原则
类应该对修改关闭,对扩展打开。一个软件的实体应当对扩展开放,对修改关闭。

我的理解是,对于一个已有的软件,如果需要扩展,应当在不需修改已有代码的基础上进行。

OCP 关注的是灵活性,改动是通过增加代码进行的,而不是改动现有的代码;
OCP的应用限定在可能会发生的变化上,通过创建抽象来隔离以后发生的同类变化
OCP原则传递出来这样一个思想:一旦你写出来了可以工作的代码,就要努力保证这段代码一直可以工作。这可以说是一个底线。稍微提高一点要求,一旦我们的代码质量到了一个水平,我们要尽最大努力保证代码质量不回退。这样的要求使我们面对一个问题的时候不会使用凑活的方法来解决,或者说是放任自流的方式来解决一个问题;比如代码添加了无数对特定数据的处理,特化的代码越来越多,代码意图开始含混不清,开始退化。
OCP 背后的机制:封装和抽象;封闭是建立在抽象基础上的,使用抽象获得显示的封闭;继承是OCP最简单的例子。除了子类化和方法重载我们还有一些更优雅的方法来实现比如组合;

怎样在不改变源代码(关闭修改)的情况下更改它的行为呢?答案就是抽象,OCP背后的机制就是抽象和多态

没有一个可以适应所有情况的贴切的模型!一定会有变化,不可能完全封闭.对程序中的每一个部分都肆意的抽象不是一个好主意,正确的做法是开发人员仅仅对频繁变化的部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。
OCP是OOD很多说法的核心,如果这个原则有效应用,我们就可以获更强的可维护性可重用灵活性健壮性 LSP是OCP成为可能的主要原则之一
LSP: The Liskov substitution principle
子类必须能够替换基类。所有引用基类的地方必须能透明地使用其子类的对象。

LSP关注的是怎样良好的使用继承.
必须要清楚是使用一个Method还是要扩展它,但是绝对不是改变它。
LSP清晰的指出,OOD的IS-A关系是就行为方式而言,行为方式是可以进行合理假设的,是客户程序所依赖的。
LSP让我们得出一个重要的结论:一个模型如果孤立的看,并不具有真正意义的有效性。模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。而假设是难以预测的,直到设计臭味出现的时候才处理它们。
对于LSP的违反也潜在的违反了OCP
DIP:依赖倒置原则
高层模块不应该依赖于底层模块二者都应该依赖于抽象。要针对接口编程,不要针对实现编程。

我的理解是,对于不同层次的编程,高层次暴露给低层次的应当只是接口,而不是它的具体类。

A. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象

B. 抽象不应该依赖于细节,细节应该依赖于抽象

抽象不应该依赖于细节,细节应该依赖于抽象

什么是高层模块?高层模块包含了应用程序中重要的策略选择和业务模型。这些高层模块使其所在的应用程序区别于其它。
如果高层模块依赖于底层模块,那么在不同的上下文中重用高层模块就会变得十分困难。然而,如果高层模块独立于底层模块,那么高层模块就可以非常容易的被重用。该原则就是框架设计的核心原则。
这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口,而服务者从这些抽象接口派生。
这就是著名的Hollywood原则:"Don‘t call us we‘ll call you."底层模块实现了在高层模块声明并被高层模块调用的接口。
通过倒置我们创建了更灵活更持久更容易改变的结构
DIP的简单的启发规则:依赖于抽象;这是一个简单的陈述,该规则建议不应该依赖于具体的类,也就是说程序汇总所有的依赖都应该种植于抽象类或者接口。
如果一个类很稳定,那么依赖于它不会造成伤害。然而我们自己的具体类大多是不稳定的,通过把他们隐藏在抽象接口后面可以隔离不稳定性。
依赖倒置可以应用于任何存在一个类向另一个类发送消息的地方
依赖倒置原则是实现许多面向对象技术多宣称的好处的基本底层机制,是面向对象的标志所在。
ISP:接口隔离原则
不应该强迫客户程序依赖它们不需要的使用的方法。接口的设计应该遵循最小接口原则,不要把用户不使用的方法塞进同一个接口里。

接口不是高内聚的,一个接口可以分成N组方法,那么这个接口就需要使用ISP处理一下。
接口的划分是由使用它的客户程序决定的,客户程序是分离的接口也应该是分离的。
一个接口中包含太多行为时候,导致它们的客户程序之间产生不正常的依赖关系,我们要做的就是分离接口,实现解耦。
应用了ISP之后,客户程序看到的是多个内聚的接口。

怎样在实践中遵守这些原则?
使用三种视角思考问题就是答案之一。

本文内容包括:

1.为什么我们过早的纠缠于细节?问题的本质是什么?

2.救命稻草--Martin Fowler的三层视角理论

3.三层视角--回头再说OO设计原则

为什么我们过早的纠缠于细节?问题的本质是什么?
         做设计时过早的关注细节几乎是多数程序员的泥沼,也是我自己的顽疾。就像我刚开始工作不久要做一个自动更新的系统,设计会议上开发组老大定了使用FTP协议完成,你知道我脑袋里面想的是什么?--“Indy组件好像不支持中文”…...
      过早的关注细节,大体上可能有两种原因:1.经验丰富,举一反三,纲举目张,各种技术玄妙如数家珍 2.没有什么经验,只知道点技术细节,难以跳出思维桎梏;我知道我是后者,以前是现在也是。

人是有惰性的,人们习惯性的做自己熟练精通的事情。所以做设计的时候,当对大框架缺少把握能力的时候,潜意识里我更愿意去思考那些细节。这是在偷懒,所有的技术细节、问题都是没有疑问的(我们不是做科研),或者是有疑问你可以很容易获得解答无论是开发文档还是在社区。细节的解决方案总是显而易见,但并非肯定是最好的入手点。

有时候我真的要做设计了,我想要避免陷入“细节泥沼”可是我还是无意中把细节扯进来,这是为什么?剖析自己,我知道这是因为我的思考是平铺的,是没有层次的,所有的问题搅在一起,做设计的时候难免拖泥带水,泥沙俱下。

思考没有层次这就是问题本质所在,我要做好设计,而思维方式上的缺陷成为我的命门所在,我该怎么办?说实话我一直在走弯路,而且不知道现在的这条路是否对头。
        “善良的人在追求的中纵然迷茫,却终将意识到有一条正途.”-----《浮士德》

救命稻草--Martin Fowler的三层视角理论
     Martin Fowler在他的著作《UML Distilled》中提到了三层视角(perspective):概念视角,规约视角,实现视角。

使用三种视角看软件开发,我们可以得到这样的描述:

概念视角:呈现所研究领域中的各种概念,得出概念模型的时候应该尽量少德或者不考虑它的实现,这个视角要回答的问题是:软件要负责什么?是策略性的结论

规约视角:我们现在考虑的是软件,但是我们关注的是软件的接口而不是实现。规约视角要回答的问题是:怎么使用软件?这个层次关注的是软件各部分的交流。

实现:这时我们考虑的是代码本身但是许多方面我们使用规约视角可能会更好,软件在规约层交流在实现层执行。

视角帮助我们将问题划分层次,隔离

从上面的描述我们很明显得看到“软件开发”所设计牵扯的问题已经被划分到三个不同的层次,在每一个层次我们都要有特定的思考成果。在高层没有思考成熟的时候我们不往下一个层次进行,按照这样一个原则,细节被隔离在思维的围墙之外。

原文地址:https://www.cnblogs.com/cgfpx/p/11652336.html

时间: 2024-10-10 04:56:12

OO六大设计原则的相关文章

设计模式之六大设计原则

在上篇博文中提到了开放-封闭原则,没有细谈,这次我们来总结一下设计模式的几大原则. 1开放-封闭原则:是指软件实体(类.模块.函数等)应该可以扩展,但是不可修改. 对原则的理解:开闭原则是最具有理想主义色彩的一个原则,它是面向对象设计的终极目标,下面所要介绍的几个原则可以看成是为了符合开闭原则所作的努力和解决办法.对于开闭原则通俗的理解就是,能不改就不改,能少改尽可能的少改.周所周知,物质是运动的,世界是变化的,想要让一个事物永恒不变是不可能的,所以要想让软件绝对符合开闭原则是不可能的. 2单一

设计模式中的六大设计原则之三,四

求二叉树的宽度和深度 给定一个二叉树,获取该二叉树的宽度和深度. 例如输入 a / \ b c / \ / \ d e f g 返回3. 详细描述: 接口说明 原型: int GetBiNodeInfo(BiNode &head, unsigned int *pulWidth, unsigned int *pulHeight) 输入参数: head 需要获取深度的二叉树头结点 输出参数(指针指向的内存区域保证有效): pulWidth 宽度 pulHeight 高度 返回值: 0 成功 1 失败

设计模式小结——六大设计原则

设计模式是一套由软件界前辈们总结出的可以反复使用的编程经验,旨在提高代码的可重用性,提高系统的可维护性,以及解决一系列复杂问题.设计模式包括6大设计原则和23种种设计模式.6大设计原则:单一职责原则SRP 应该有却仅有一个原因引起类的变更,即类最好只实现一种功能.高内聚. 单一职责的实现方式是一个职责一个接口. 单一职责适用于类和接口,同样适用于方法,一个方法也应该只做好一件事.里氏替换原则LSP 所有能使用父类的地方必须能透明地使用其子类的对象. 子类必须完全实现父类的方法,如果子类不能完整实

浅谈Java六大设计原则

笔者刚接触设计原则的时候,觉得一头雾水,不知道他有什么用.在经历了一段时间的代码加上了解Java设计模式之后.笔者忽然觉得自己以前写的代码就是一堆*.所以,笔者认为设计原则和设计模式对于软件编程设计(非码农)来说是至关重要的事情.相信很多学习编程的人,和我有同样的感受. 我对设计模式和设计原则的理解是:如果把程序员比作武侠,那么设计模式就是修炼内功的易筋经,设计原则就是修炼内功的心法总纲,而具体的技术实现(代码编写)就是罗汉拳.如果你只想自保,那么会罗汉拳就可以了(能够用代码实现功能),不过如果

OO的设计原则

今天同事和我们一起讨论分享了OO的设计原则,讨论使人明晰,有人一起讨论学习是一件幸福的事情. 1.开闭原则 对功能的扩展是开放的,对修改是闭合的. 可以应用于类的设计,框架的设计等. 为什么?开闭原则有利于保护已有的客户端代码,让原有的代码不会因为框架的扩展修改而发生变动,减少维护的成本. 如果你设计的框架经常变动,而且每次变动使使用的人要改很多,那么没人敢用了. 2.单一职责原则 应用于实现类,如果类有变化,那么引起变化的原因仅有一个 为什么?如果你在设计类的时候,没有进行接口拆分设计,直接封

设计模式中的六大设计原则之一,二

最近在学习设计模式方面的知识,首先接触到的是设计模式中的六大设计原则: 1.单一职责原则: 2.里氏替换原则:3.依赖倒置原则:4.接口隔离原则:5.迪米特法则:开闭原则.下面我来讲讲我对这六大设计自己的理解,如有欠缺地地方,请大家及时指出啊...   1.单一职责原则:应该有且仅有一个原因引起类的变更.通俗的说,即一个类只负责一项职责.下面我们举一个具体的例子来说明一下什么是单一职责原则.电话通话的时候有4个过程发生:拨号,通话,回应,挂机,首先看下面这样一个借口,如图1所示: 图1. 我们来

六大设计原则浅析

一.设计在软件开发中的重要性 重要性 在上大学的时候我们总是不理解为什么要讲这么理论性的东西,当时就一个感觉就是没什么用,我们更想去学习一些可以看到结果的东西,当你毕业之后就会发现基础的知识是多么重要,而这些知识都有一个共性就是可以脱离具体的技术或者问题而存在,是一种可以长期指导我们学习和进步的重要思想,设计原则和模式就是软件开发中的这种思想. 设计原则 我们先来思考一个问题: 怎么样的软件才算一个好的软件或者说对于程序员我们如何评价他(她)的编码技术? 我们来假设一个项目是由某个程序员独立去完

C#设计模式:六大设计原则

面向对象的典型原则 可以划分两类:面向类的和面向包. 面向类的包括: SRP--单一职责原则. OCP--开放封闭原则. LSP --里氏替换原则. DIP--依赖倒置原则. ISP--接口隔离原则. 面向包的包括: 强调的是包的内聚性设计要求->REP--重用发布等价原则. CCP--共同封闭原则. CRP--共同重用原则. 针对是包间耦合性要求->ADP--无环依赖原则. SPP--稳定依赖原则. SAP--稳定抽象原则. 六大设计原则: 单一职责原则 SRP-- Single Respo

十年阿里java架构师的六大设计原则和项目经验

先看一幅图吧: 这幅图清晰地表达了六大设计原则,但仅限于它们叫什么名字而已,它们具体是什么意思呢?下面我将从原文.译文.理解.应用,这四个方面分别进行阐述. 1.单一职责原则(Single Responsibility Principle - SRP) 原文:There should never be more than one reason for a class to change. 译文:永远不应该有多于一个原因来改变某个类. 理解:对于一个类而言,应该仅有一个引起它变化的原因.说白了就是