OO设计原则总结

什么是设计原则?

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

基本原则

封装变化Encapsulate what varies. 面向接口变成而不是实现 Code to an interface rather than to an implementation. 优先使用组合而非继承 Favor Composition Over InheritanceSRP: The single responsibility principle 单一职责

系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成。

Every object in your system should have a single responsibility ,and all the object s services should  be focused on carrying out that single responsibility .

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

通过抽取公共部分放置在一个地方避免代码重复.

Avoid duplicate code by abstracting out things that are common and placing those thing in a single location .

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

OCP : Open-Close Principle开闭原则

类应该对修改关闭,对扩展打开;

Classes should be open for extension ,and closed  for modification .

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

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

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

子类必须能够替换基类。

Subtypes must be substitutable  for their base types.

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

高层模块不应该依赖于底层模块 二者都应该依赖于抽象

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

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

不应该强迫客户程序依赖它们不需要的使用的方法。

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

请看本文的续篇:视角的力量--再说OO设计原则

时间: 2024-10-21 08:08:01

OO设计原则总结的相关文章

艾伟:OO设计原则总结

什么是设计原则? 设计原则是基本的工具,应用这些规则可以使你的代码更加灵活.更容易维护,更容易扩展. 基本原则   封装变化Encapsulate what varies. 面向接口变成而不是实现 Code to an interface rather than to an implementation. 优先使用组合而非继承 Favor Composition Over Inheritance SRP: The single responsibility principle 单一职责 系统中的

设计模式之(1)设计原则

*开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为. *.UML(统一建模语言, Unified Modeling Language),是OMG(Object Management Group)在1997年发表的图标式软件设计语言. 1.类图中的关系:(1).一般化关系:(Generalization)  

面向设计原则理解

    面向对象设计(OOD)核心原则让我的程序模块达到"高内聚低耦合",这是来自于30年前兴起的结构化设计(structured Design),但是同样适用于我们的OOD. 1.高内聚:     高内聚是指某个特定模块(程序,类型)都应完成一系列相关功能,描述了不同程序,类型中方法,方法中不同操作描述的逻辑之间的距离相近.高内聚意味可维护性,可重新性,因为模块对外部的依赖少(功能的完备性).如果两个模块之间的修改,互不影响这说明模块之间是高内聚的.模块的内聚和其担当的职责成反比,即

连载:面向对象葵花宝典:思想、技巧与实践(39) - 设计原则 vs 设计模式

又是设计原则,又是设计模式,到底该用哪个呢? ============================================================================= 在"设计模型"一章中,我们提到设计原则和设计模式是互补的,设计原则和设计模式互补体现在:设计原则主要用于指导"类的定义"的设计,而设计模式主要用于指导"类的行为"的设计.   举一个很简单的例子:假设我们要设计一个图形类Shape,这个类既支持三角

这样做违反了JAVA设计原则吗?

问题描述 我们也许都写过下面的代码现在随着业务的发展,除了D类外,其它子类都需要增加doOtherThing方法,于是我们这样处理:同时D类的doOtherThing方法的写法是:publicvoiddoOtherThing(){//donothing;}请问这么做有什么问题?违反了面向对象设计原则中的哪个原则?如何改进呢? 解决方案 解决方案二:不会影响运行效率放着就放着吧解决方案三:没什么问题,你要是违反了面向对象设计原则中的哪个原则就是D类不应该出现doOtherThing这个方法用接口去

Android界面与交互设计原则:以用户为中心

译者按: 在iOS HIG已经强大经典了N年之后,Android终于推出了一套比较系统的HIG(大概是为了配合Android 4.0 Ice Cream Sandwich).仔细比较两套HIG的"设计原则"部分,发现完全是截然不同的两种风格.iOS HIG走的是更专业型的路线,描述严谨且有不少的专业词汇(比如Metaphors.Consistency之类的).而Android则显得亲民许多,不仅描述方式简要易懂,配图鲜明直观,甚至还用了"me"作为了一系列要点的标题

微服务的4大设计原则和19个解决方案

作者|郝炎峰 编辑|小智 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 注:本文转载自公众号 EAWorld,已获授权. 写在前面 微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以 SpringCloud 为基础

微服务的4个设计原则和19个解决方案

微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验,逐步孵化的一个微服务应用平台. 一.微

专注产品UI设计:移动界面设计原则和设计工具

文章描述:移动界面设计点滴. 移动平台的设计与传统的网页有许多不同之处,如独特的交互体验.不同光线下的视觉效果以及移动终端的资源有限.这些都考验着开发者的技术. 通过对设计移动界面的点滴记录,本文为读者介绍了对界面的规划的设计原则以及相关案例,并且推荐了自己中意的设计工具. 一.减少空间占用 与面向桌面电脑的网页设计不同,移动平台的设计中,屏幕空间是一个不可忽视的限制因素.设计需要符合移动平台用户的使用习惯,以最佳的状态呈现屏幕信息. 接下来以当前正在工作的UI做为sample,实战空间优化.