基本原则:

封装变化Encapsulate what varies.

面向接口编程而非实现 Code to an interface rather than to an implementation.

优先使用组合而非继承 Favor Composition Over Inheritance

1.SRP----单一责任原则

2.OCP----开闭原则

3.LSP----Liskov替换原则

4.DIP----依赖倒置原则

5.ISP----接口分离原则

  敏捷开发提倡简单设计的实践,“并在实现新需求时抓住机会改进设计”以对同类性质的改动封闭,做到由需求的变化驱动设计的进化(我们不能因为设计的退化而责怪需求的变化),同时经验在此起到十分重要的作用,如有经验的设计人员可以凭经验在初始设计时做出必要的抽象来满足ocp原则等,或是在需求变动时确定系统所需的抽象(所需的封闭),当然应及早的刺激这种变化的出现(如测试驱动的开发方法)。

  OOD承诺了一系列的好处(灵活性可重用性可维护性),用OO语言设计开发,若要方便的得到这些所谓的好处,有一系列的原则是要遵循的,如SRP,OCP,LSP,ISP等。

   SRP(单一职责原则)维护类的简单性,类不应承担一个以上令其变化的原因,否则应考虑分离并重新构造类,但如果的应用的变化方式总是导致类中的职责同时变化,却没必要分离他们

  Ocp(开闭原则)使OO系统做到对扩展开放,对修改封闭。OCP的遵循关键在于抽象,其主要实现方式有:定义接口描绘所需的操作,client只需关注接口的调用,子类型可以以任何其选择的方式实现接口,即所谓的stategy模式,或者定义抽象类并于其中实现公共操作,个性操作定义为abstract或virtual,由子类型负责个性化实现,通过此两法,将功能的通用部分和实现细节分离出来。当然,设计人员应该确定(猜测或凭经验)系统对哪种变化做到封闭,因为不可能对所有变化做到封闭,如《敏捷模式实践》中提到shape类型排序处理问题,为做到对排序安排(或变动)的封闭(使得各子类型间无需相互知晓,也可以做到自由安排排序顺序),选择使用“数据驱动”的方式(即单独构造结构表示排序安排—其中以子类类型在结构中的排列位置表先后),于shape基类中实现一次Precedes操作即可,子类型无需分别实现。OCP作为OOD核心所在依赖抽象来实现,但敏捷设计(或者说好的设计)拒绝不成熟的抽象,程序仅应对频繁变化的部分做出抽象。

  Liskov替换原则是使得ocp成为可能的原则之一,强调“子类型subtype必须能够替换掉它们的基类型basetype”,控制OO的继承关系安排,在OOD用is-a来确定类间的继承关系,LSP指出这种is-a关系是就行为方式(即类的各操作)而言的,而行为方式是可以合理假设的,是客户程序所依赖的。为遵循LSP,可借用DBC(design by contract)的操作前置条件和后置条件,“要使操作得以执行,前置条件必须为真,执行完毕后,该操作要确保后置条件为真”(为每个方法注明其前置和后置条件十分有帮助),如此,则“在重新声明派生类中操作时,只能使用相等或更弱的前置条件来替换原始的前置条件,只能用相等或更强的后置条件来替换原始的后置条件”(interface和其实现类间 抽象方法和其实现 此二者一定满足前述条件)。同时亦可用前述ocp遵循所用的二模式使设计符合LSP,另外子类型中的异常抛出应考虑在遵循LSP的范围内。

  关于提取公共部分的设计工具:“提取公共职责放入超类中,稍后添加的新的子类型可能会以新的方式支持同样的职责,此时原来的超类可能会是一个抽象类”。

DIP(依赖倒置原则),作为framework的设计核心,其相对于传统软件设计而言,通常(传统)软件设计中采用结构化设计用高层模块直接调用底层模块,这样高层模块将严重依赖于底层模块的变动,在OOD中通过为高层模块定义所需使用的服务接口,底层模块现实这样的接口,高层模块通过抽象接口使用下一层(strategy模式所声明的),如此看来接口的拥有者一般是其使用者而非其实现者。通常为了满足DIP-良好OOD的基本底层机制,我么需要找出系统中潜在的抽象,而抽象通常是那些不随具体细节变化而变化的东东。

ISP接口隔离原则,如SRP维护类的简单性一样,ISP用于维护接口的简单和必要性,因为接口是为客户调用的,因此其应该是“大小尺寸合适的”,“胖”接口显然对调用者造成累赘,ISP则用于将“胖”接口分离成多个合适的接口。

当然,在系统设计实现中要做到这些并非容易,单单知道其存在未必做得到将其实现到系统中,开发经验的积累同样重要,但早些知道存在个意识并在做时将其考虑进去,也是积累,慢慢来吧,n多事要做呐。

                                                                                                   ——敏捷软件开发:原则 模式与实践

==================================另外一个版本

什么是设计原则?

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

基本原则

  • 封装变化Encapsulate what varies.
  • 面向接口编程而不是实现 Code to an interface rather than to an implementation.
  • 优先使用组合而非继承 Favor Composition Over Inheritance

SRP: 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 .

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

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

OCP : Open-Close Principle开闭原则

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

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

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

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

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

LSP: The Liskov substitution principle

子类必须能够替换基类。

Subtypes must be substitutable for their base types.

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

DIP:依赖倒置原则

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

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

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

ISP:接口隔离原则

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

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

程序员的基础教程:菜鸟程序员

oo原则的更多相关文章

  1. Bob大叔观OO原则

    Bob大叔观OO原则 上篇总结了经典的23种 设计模式,详细的解读后期会陆续的详细揭开.使用设计模式的根本原因就是为了增强代码的复用性和可维护性.而面向对象是实现代码复用的有效途径,所以这里有必要了解 ...

  2. 跟Bob大叔观OO原则

    上篇总结了经典的23种 设计模式,详细的解读后期会陆续的详细揭开.使用设计模式的根本原因就是为了增强代码的复用性和可维护性.而面向对象是实现代码复用的有效途径,所以这里有必要了解一下OO的基本思想和原 ...

  3. OO原则汇总

    SOLID原则:http://www.cnblogs.com/lanxuezaipiao/archive/2013/06/09/3128665.html https://www.cnblogs.com ...

  4. 对OO原则的个人理解

    1.单一职责原则.(Single Responsibility Principle) 注解:社会化大生产分工要细.具体每个人最好只做一件事(不要一人兼多职),这样如果这个人请假或辞职,对生产不会产生影 ...

  5. OO真经——关于面向对象的哲学体系及科学体系的探讨(下)

    真经第六章——运作 Moving “运动是绝对的——牛顿” 6.1.导言 在前五章中,我们从世界观的这话题开始,逐步引出了抽象.层次.继承和耦合.这些内容,形成了对象论中关于世界的结构体系.      ...

  6. OO设计基本原则

    OO本身就是一种大的设计模式,它是随着软件规模越来越大产生出来帮助人们建模和开发的理念,生来就带着封装.继承.多态等可复用基因.为了充分发挥这些基因的功效,使用者需要遵守一定的原则,就是所谓的面向对象 ...

  7. 这些年一直记不住的 Java I/O

    参考资料 该文中的内容来源于 Oracle 的官方文档.Oracle 在 Java 方面的文档是非常完善的.对 Java 8 感兴趣的朋友,可以从这个总入口 Java SE 8 Documentati ...

  8. 学C#之设计模式系列笔记(2)观察者模式

    一.借鉴说明 1.<Head First Design Patterns>(中文名<深入浅出设计模式>) 2.维基百科,观察者模式,https://zh.wikipedia.o ...

  9. 学C#之设计模式系列笔记(1)策略模式

    一.借鉴说明 1.<Head First Design Patterns>(中文名<深入浅出设计模式>) 2.维基百科,策略模式,https://zh.wikipedia.or ...

随机推荐

  1. beego的配置文件记录

    摘自https://github.com/beego/tutorial/blob/master/zh/3/params.slide * beego的默认参数 - AppName 应用名称,默认是 be ...

  2. python接口自动化22-签名(signature)鉴权(authentication)之加密(HEX、MD5、HMAC-SHA256)

    前言 开放的接口为了避免被别人乱调用,浪费服务器资源,这就涉及到签名(Signature)加密了 API 使用签名方法(Signature)对接口进行鉴权(Authentication).每一次请求都 ...

  3. Java经典练习题_Day04

    一.选择题 1. 下列关于数组的说法正确的是:(A) A. 在Java中数组的长度是可变的 B. 数组中存储的数据的类型是相同的 C. 数组在进行扩容操作的时候源数组的地址不发生改变 D. int[] ...

  4. 汇编_压缩BCD码和非压缩BCD码

    BCD码是表示十进制数的,非压缩BCD码是用8位表示的,其实只用低4位,高4位全为0. 例如,十进制数36,用非压缩BCD码表示为:0000 0011 0000 0110 ,这是两个字节. 压缩BCD ...

  5. 017:磁盘I/0介绍和测试

    一. 磁盘 1. 磁盘的访问模式 顺序访问 顺序的访问磁盘上的块: 一般经过测试后,得到该值的单位是MB/s,表示为磁盘带宽,普通硬盘在 50~ 100 MB/s 随机访问 随机的访问磁盘上的块 也可 ...

  6. 【UVa】12118 Inspector's Dilemma(欧拉道路)

    题目 题目     分析 很巧秒的一道题目,对着绿书瞎yy一会. 联一下必须要走的几条边,然后会形成几个联通分量,统计里面度数为奇数的点,最后再减去2再除以2.这样不断相加的和加上e再乘以t就是答案, ...

  7. 为什么多线程读写 shared_ptr 要加锁?

    https://www.cnblogs.com/Solstice/archive/2013/01/28/2879366.html 为什么多线程读写 shared_ptr 要加锁? 陈硕(giantch ...

  8. 使用product_user_profile来实现用户权限的设定

    我们有时候在以普通用户登录SQL*Plus的时候,会碰到下面的错误提示: Error accessing PRODUCT_USER_PROFILE Warning: Product user prof ...

  9. ubuntu apt-get dpkg-scanpackages 制作本地软件源

    1. 收集软件,下载的软件都在/var/cache/apt/archives目录下 例如openstack L版的所有包 keystone,glance nova neutron....... 举例: ...

  10. canvas旋转文本

    canvas旋转文本 <!DOCTYPE html> <html lang="en"> <head> <meta charset=&quo ...