精华内容
下载资源
问答
  • 北京大学软件工程国家工程研究中心 王立福 的讲搞 PPT格式的讲稿, 内容都是精华!
  • 二、敏捷开发设计原则关于敏捷开发设计原则:单一职责原则SRP:Single Responsibility Principle开放封闭原则OCP:Open-Close PrincipleLiskov替换原则LSP:Liskov...
    二、敏捷开发的设计原则

    关于敏捷开发的设计原则:
    单一职责原则SRP:Single Responsibility Principle
    开放封闭原则OCP:Open-Close Principle
    Liskov替换原则LSP:Liskov Substitution Principle
    依赖倒置原则DIP:Dependency Invertion Principle
    接口隔离原则ISP:Interface Separate Principle
    关于包的设计原则:
    重用发布等价原则REP:Reuse Equivalence Principle
    共同重用原则CRP:Common Resue Principle
    共同封闭原则CCP:Common Close Principle
    无环依赖原则ADP:Acyclic Dependency Principle
    稳定依赖原则SDP:Stabilization Dependency Principle
    稳定性度量公式:I=Ce/(Ca+Ce) (I:不稳定度,Ce:输入耦合度,Ca:输出耦合度)
    I取值范围在【0,1】,I=0表示具有最大稳定度;iI=1标识具有最大不稳定度
    稳定抽象原则SAP:Stabilization Abstract Principle

     

    GOF说--基于对象组合的设计会有更多的对象(而有较少的类)。
    如果单纯的看这里,你会明白似乎类较少符合面向对象的逻辑。
    但是且慢,我们知道面向对象有一条原则叫单一职责原则--SRP。
    这样好像类多又是面向对象思想的体现。
    其实最重要的是GOF中的这句话--且系统的行为将依赖对象间的关系而不是被定义在某个类中。
    所以类的多少并不是问题的关键,是否职责单一也不是大问题,
    最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。
    在BOB大叔那里定义职责是变化的原因,因此就可以认为这些变化的原因应该是不可代替的,
    也可以说你不能由这个原因推导出别的原因。
    只要这个原因间可以做到相互关联,那么你就可以把由于这些变化而引起变化的类组合起来,
    而不是把他们规定在新的类中。


    开放封闭原则OCP:Open-Close Principle

    一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。

    因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。

    该原则同样适合于非面向对象设计的方法,是软件工程设计方法的重要原则之一。

    我们以收音机的例子为例,讲述面向对象的开闭原则。

    我们收听节目时需要打开收音机电源,对准电台频率和进行音量调节。

    但是对于不同的收音机,实现这三个步骤的细节往往有所不同。

    比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。

    因此,我们不太可能针对每种不同类型的收音机通过一个收音机类来实现(通过重载)这些不同的操作方式。

    但是我们可以定义一个收音机接口,提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。

    不同的收音机继承并实现这六个抽象方法。

    这样新增收音机类型不会影响其它原有的收音机类型,收音机类型扩展极为方便。

    此外,已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。
    图1是一个应用OCP生成的收音机类图的例子:

    Liskov替换原则LSP:Liskov Substitution Principle

    子类应当可以替换父类并出现在父类能够出现的任何地方。

    我们以学生为例,夜校生为学生的子类,因此在任何学生可以出现的地方,夜校生均可出现。

    这个例子有些牵强,

    一个能够反映这个原则的例子时圆和椭圆,圆是椭圆的一个特殊子类。

    因此任何出现椭圆的地方,圆均可以出现。但反过来就可能行不通。
     

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/3433/viewspace-269190/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/3433/viewspace-269190/

    展开全文
  • 敏捷开发设计原则

    2007-04-02 23:40:00
    关于敏捷开发设计原则:单一职责原则SRP:Single Responsibility Principle开放封闭原则OCP:Open-Close PrincipleLiskov替换原则LSP:Liskov Substitution Principle依赖倒置原则DIP:Dependency Invertion ...

    关于敏捷开发的设计原则:
    单一职责原则SRP:Single Responsibility Principle
    开放封闭原则OCP:Open-Close Principle
    Liskov替换原则LSP:Liskov Substitution Principle
    依赖倒置原则DIP:Dependency Invertion Principle
    接口隔离原则ISP:Interface Separate Principle
    关于包的设计原则:
    重用发布等价原则REP:Reuse Equivalence Principle
    共同重用原则CRP:Common Resue Principle
    共同封闭原则CCP:Common Close Principle
    无环依赖原则ADP:Acyclic Dependency Principle
    稳定依赖原则SDP:Stabilization Dependency Principle
    稳定性度量公式:I=Ce/(Ca+Ce) (I:不稳定度,Ce:输入耦合度,Ca:输出耦合度)
    I取值范围在【0,1】,I=0表示具有最大稳定度;iI=1标识具有最大不稳定度
    稳定抽象原则SAP:Stabilization  Abstract Principle

    GOF说--基于对象组合的设计会有更多的对象(而有较少的类)。
    如果单纯的看这里,你会明白似乎类较少符合面向对象的逻辑。
    但是且慢,我们知道面向对象有一条原则叫单一职责原则--SRP。
    这样好像类多又是面向对象思想的体现。
    其实最重要的是GOF中的这句话--且系统的行为将依赖对象间的关系而不是被定义在某个类中。
    所以类的多少并不是问题的关键,是否职责单一也不是大问题,
    最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。
    在BOB大叔那里定义职责是变化的原因,因此就可以认为这些变化的原因应该是不可代替的,
    也可以说你不能由这个原因推导出别的原因。
    只要这个原因间可以做到相互关联,那么你就可以把由于这些变化而引起变化的类组合起来,
    而不是把他们规定在新的类中。
    展开全文
  • 第七章 什么是设计模式 1. 源代码是软件系统的主要设计文档 我们不应该认为软件设计就是一组和代码分离的UML图,UML图只是描述了设计的一部分。 软件项目的设计是一个抽像的概念。它和程序的概括形状、结构以及...

    第七章 什么是设计模式

    1. 源代码是软件系统的主要设计文档

    • 我们不应该认为软件设计就是一组和代码分离的UML图,UML图只是描述了设计的一部分。
    • 软件项目的设计是一个抽像的概念。它和程序的概括形状、结构以及每一个模块、类和方法的详细形状和结构有关。
    • 设计的最终体现在 源代码 中。

    2.设计中臭味——腐化软件的气味

    • 僵化性: 耦合性高,模块组件件关系太紧密,依赖性高,一动全动。
    • 脆弱性: 改动一处,其他相关联的地方也会变动,引发意想不到的问题。
    • 牢固性: 设计难以重用。
    • 粘滞性: 这一点有点难以理解。
    • 不必要的复杂性: 导入不必要的模块,组件或包。
    • 不必要的重复: 随意copy,将可以的抽象隐藏起来,而且如果随处copy的代码(如果有错误)需要变动,得到处进行修改。
      • 【案例】:开发中,打印空指针异常信息处理方法的例子
    • 晦涩性: 模块难以理解。
    • 设计中的臭味设计中的臭味

    3.保持尽可能好的设计

    • 需求是项目中最不稳定的要素。
    • 敏捷团队依靠变化来获取活力。
    • 团队几乎不进行预先设计,因此不需要一个成熟的初始设计。
    • 敏捷开发人员致力于保持设计尽可能的适当、干净、简单,并且使用许多的单元测试和验收测试支援。
    • 敏捷软件开发知道要做的事情:
      • 他们遵循敏捷实践去发现问题
      • 他们应用设计原则去诊断问题
      • 并且,他们应用适当的设计模式去解决问题

    4.结论-什么是敏捷设计

    • 敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能的简单、干净以及富有表现力。

    5.臭味

    • 设计中的臭味是一种症状,是可以主观进行度量的。这些臭味通常是由违反了这些原则中的一个或者多个导致的。
    • 比如违反了开闭原则,会导致僵化性。
    • 应用原则的目的是去除僵化性,当没有臭味时就不应该应用这些原则

    6.敏捷设计之原则

    1. 单一职责原则(The Single Responsibility Principle,简称SRP
    2. 开放——封闭原则(The Open-Close Principle,简称OCP
    3. Liskov替换原则(The Liskov Substitution Principle,简称LSP
    4. 接口隔离原则(The Interface Segregation Interface,简称ISP
    5. 依赖倒置原则(The Dependency Inversion Principle,简称DIP

    第八章 单一职责原则(SRP)

    • 内聚性:
    • 一个模块的组成元素之间的功能相关性。把内聚性和引起一个模块或者类改变的作用力联系起来。

    • 职责: 变化的原因。
    • 原则的定义:就一个类而言,应该仅用一个引起它变化的原因。
    • 描述:
      • 每一个职责都是变化的一条轴线。当需求变化时,该变化反应为类的职责的变化。如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个。
      • 如果一个类承担的职责过多,就等于把这些职责耦合在一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
      • 这种耦合导致脆弱的设计,当变化发生时,设计会遭受意想不到的破坏。
    • Employee的例子
      • Employee类包含了业务规则和对于持久化的控制。
      • 业务规则往往会频繁的变化,而持久化的方式却不会如此频繁的变化。
      • 测试驱动开发的实践常常会远在设计出现臭味之前就迫使我们分离这两个职责。
    • 一个实例:
      • SpringIOC源码中BeanFactory的设计。
      • getBaen()和getBeanDefinition()、registerBeanDefinition()的分离。

    第九章 开放-封闭原则(OCP)

    • 原则的定义:
    • 软件实体(类,模块、函数等等)应该是可以扩展的,但是不可修改的。

    • 描述:
      • 对于扩展是开放的
      • 对于更改的封闭的
      • 开闭的原则描述开闭的原则描述

    • 本质: 构造抽象来隔离引起的变化
    • 如何知道变化的发生:
      • 进行适当的调查,提出正确的问题,并且使用我们的经验和一般常识,最终,直到我们会一直等到变化发生的时候才采取行动。
    • 结论:
    • 在许多方面,OCP都是面向对象设计的核心所在,遵循这个原则可以带来巨大好处。比如,灵活性,可重用性以及可维护性。

    第十章 Liskov替换原则(LSP)

    • 定义:
    • 子类型必须能够替换掉它们的基类型

    • 背后的本质:继承
    • 描述: 若对每个类型S的对象o1,都存在一个类型T的对象o2,使得在所有针对T编写的程序P中,用o1替换o2后,程序P行为功能不变,则S是T的子类型。
    • 隐藏的问题:一般违反LSP原则的同时,也潜在的违反了OCP原则。
    • Rectangle类与Square类违反了LSP的有趣例子
    • 结论:
    • 一个模型,如果孤立地看,并不具有真正意义上的有效性。在考虑一个特定设计是否恰当时,不能完全孤立地来看这个解决方案。必须要根据该设计的使用者所做出的合理假设来审视它。

    • 基于契约式设计(约定大于配置)
      • 契约:是通过为每个方法声明的前置条件和后置条件来指定的。
      • 要使一个方法得以执行,前置条件必须为真。执行完毕后,该方法要保证后置条件为真。
    • 继承的适用性继承的适用性

    第十一章 接口隔离原则

    • **定义:**不应该强迫客户依赖它们不用的方法
    • 胖类:意味着高耦合性,当一个客户程序要求该胖类进行一个改动时,会影响到所有其他的客户程序。
    • 分离客户就是分离接口
    • 接口隔离原则描述接口隔离原则描述

    • 分离接口的两种方式:
      • 使用委托分离接口
      • 使用多重继承分离接口

    第十二章 依赖倒置原则(DIP)

    • 定义:

    • a.高层模块不应该依赖于低层模块。两者都应该依赖于抽象。
      b.抽象不应该依赖于细节。细节应该依赖于抽象。

    • 依赖倒置原则描述依赖倒置原则描述

    • 设计的层次化;

      • 所有结构良好的面向对象架构都具有清晰的层次定义,每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。
      • 这里的倒置不仅仅是依赖关系的倒置,它也是接口所有权的倒置。
    • 依赖于抽象: 程序中所有的依赖关系都应该终止于抽象类或者接口。

      1. 任何变量都不应该持有一个指向具体类的指针或者引用。
      2. 任何类都不应该从具体类派生。
      3. 任何方法都不应该覆写它的任何基类中的已经实现了的方法。
    • java是静态编程语言,python是动态编程语言。

    参考博客:
    展开全文
  • 敏捷开发 开发原则

    2014-03-14 09:28:40
    [b]计划游戏:如今的SCRUM敏捷方法论的原型。核心概念是拆分软件开发任务,排优先级,迭代式增量开发。[/b] [code="java"] 小规模发布:主要思想是软件发布/部署应该提高频度,增量发布/部署。[/code] ...
    [b]计划游戏:如今的SCRUM敏捷方法论的原型。核心概念是拆分软件开发任务,排优先级,迭代式增量开发。[/b]
     小规模发布:主要思想是软件发布/部署应该提高频度,增量发布/部署。

     简单设计:是指让系统保持越简单越好——无论将来的变化会让我们如何担忧。

     测试:是指程序员,甚至客户,应该编写自动化测试程序,来验证产品代码是否是按设计的方式运行。如今我们把它称作测试驱动开发(TDD)和确认测试驱动开发(ATDD)。

      重构:是指软件的内部结构可以、并且应该做持续的改进

      结队编程:是说团队成员如果各自独立工作就不能称之为团队。团队成员必须有规律的合作——在键盘上。这样,他们能充分分享团队其他成员应该知道的知识。

      集体所有制:是指代码归团队共有,不属于个人

     每周工作40小时:是说经常加班的团队是失败的团队。

      现场客户:是指来自业务方、负责需求的人,必须有准备的全程和开发团队保持畅通交流。

     编码标准:是指开发团队要采用一种固定的代码风格,用来提高代码整洁和方便交流。
    展开全文
  • 敏捷开发中的设计原则

    千次阅读 2012-11-17 22:13:56
    敏捷性是以微小增量的方式构建软件,那么我们该如何设计软件呢?在敏捷团队中,全局视图和软件一起演化。每次迭代,团队都改进系统设计...在《敏捷软件开发:原则、模式和实践》一书中提出几种设计原则: 单一职责原
  • 敏捷联盟与原则 在2001年召开的研讨软件过程未来发展趋势的一次会议上,17位业界专家就什么是“敏捷”达成一致意见。这次会议的一个成果是成立了“敏捷联盟”并发布了联盟敏捷宣言(参考...
  • 敏捷开发原则

    2017-09-06 22:36:56
    敏捷开发原则 不要为代码添加基于猜测的、实际不需要或并不一定需要或目前暂时不需要的功能。 如果不清楚一个系统是否需要某个功能或采用某种设计结构,则一般不要急于去实现它或急于去采用这种设计模式。 实际上,...
  • 具体的可以看看这本书:Agile.Principles.Patterns.and.Practices.in.C.Sharp 敏捷软件开发宣言 我们正通过亲身实践以及帮助他人实践,揭示更好的软件开发方法 通过这项工作,我们认为: 人和交互 重于 过程和...
  • 以下内容参考敏捷软件开发原则、模式与实践以及设计模式之面向对象与类基础特征概念、设计模式之面向对象七大基本原则 面向对象基础概念 面向对象三大基本特征 封装 封装是把过程和数据包围起来,对数据的访问只能...
  • 敏捷软件开发》学习笔记:敏捷设计原则 2011-2-15 什么是敏捷设计 遵循敏捷实践去发现问题;应用设计原则去诊断问题;应用适当的设计模式去解决问题。 软件开发这三个方面件的相互作用就是设计。 单一职责...
  • 一、面向对象设计原则内容来自《敏捷开发:原则、模式与实例》 SRP单一职责原则(Single Responsibility Principle): 就一个类而言,应该仅有一个引起它变化的原因。 OCP开放-封闭原则(Open Closure Principle...
  • 本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第12章。 接口隔离原则(ISP - The Interface Segregation Principle) 不应该强迫客户依赖于它们不用的方法。 这个原则用来处理“胖”接口所...
  • 本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第9章。 里氏替换原则(LSP - The Liskov Substitution Principle) 子类型必须能够替换掉它们的基类型。 问题 对于LSP的违反常常会导致以...
  • 本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第11章。 依赖倒置原则(DIP - The Dependency-Inversion Principle) a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。 b. 抽象不...
  • SRP: 单一职责 ...我想,设计模式的一个弊端就是让程序员不自觉的忽略(或弱化)了逻辑实体(类实例)之间的同步控制, 或者说增加了复杂度,以至于难于控制. 单一职责的极端是没有类的抽象,没有分组,没有归类. ...
  • 本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第20章后半部分 包的耦合性原则 无环依赖原则(ADP - The Acyclic Dependencies Principle ) 在包的依赖关系图中不允许存在环。 解除依赖环...
  • 单一职责原则(SRP)   开发-封闭原则(OCP) 依赖倒置原则(DIP) 接口隔离原则(ISP)
  • 下载地址:网盘下载 在本书中,享誉全球的软件开发专家和软件工程大师...这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 下载地址:网盘下载 转载于:...
  • 本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第20章前半部分 包的内聚性原则 重用发布等价原则(REP - The Reuse/Release Equivalence Principle) 重用的粒度就是发布的粒度 REP指出,...
  • 编写单元测试是一种验证行为,更是一种设计行为。测试时一个无价的文档。如果你想知道如何调用一个函数或者创建一个对象,会有一个测试展示给你看。什么是设计?不应该认为设计就是一组和代码分离的UML图。一组UML图...
  • 单一责任原则 (SRP - Single-Responsibility Principle) 就一个类而言,应该仅有一个引起它变化的原因。 在SRP中,我们把职责定义为‘变化的原因’。如果你能够想到多于一个的动机去改变一个类,那么这个类就...
  • 设计的臭味 僵化性 僵化性是指难以对软件进行改动,即使是最简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动,那么设计就是僵化的。必须要改动的模块越多,设计就越僵化。 脆弱性 脆弱性...
  • 开放-封闭原则 (OCP - The Open/Closed Principle) 软件实体(类、模块、函数等等)应该是可以扩展的,但是不能修改的。 对于扩展是开放的。对于更改是封闭的。 关键是抽象 一般而言,无论模块是多么的“封闭...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,165
精华内容 466
热门标签
关键字:

敏捷开发设计原则