敏捷软件开发_设计原则<三>】的更多相关文章

敏捷软件开发_设计原则 单一职责原则(single responsibilities principle,SRP) 原理:一个类应该只有一个变化 分离职责:如果不耦合的职责那么很简单,如果两个职责耦合,将两个职责抽象为接口,通过继承两个接口将依赖关系抽离处理啊 开放封闭原则(open close principle,OCP) 软件实体(类,模块,函数等)应该是可以扩展的,但是不可修改 对扩展开放:当需求改变时,对模块可以扩展. 对修改封闭:对模块进行扩展时,不必改动模块的源代码或则二进制代码,…
敏捷软件开发_实例1 这本书的实例非常好,给了我非常多的启发.主要讲了两个实例,咖啡机和薪水支付实例,咖啡机实例比较简单并没有用什么设计模式,薪水支付实例用了很多设计模式,包括后面的打包等. 咖啡机实例 做一个使用咖啡机的软件,驱动接口已经被写好. 咖啡机的硬件包括: 加热器加热棒(开关) 保温盘加热棒(开关) 保温盘传感器(保温盘空,杯子空,杯子不空) 加热器传感器(有水,没水) 冲煮按钮(开关) 指示灯(开关) 减压阀门(开关) 咖啡机的冲煮流程: 咖啡机一次煮12杯咖啡, 咖啡加入过滤器,…
敏捷软件开发_实例2 上一章中对薪水支付案例的用例和类做了详细的阐述,在本篇会介绍薪水支付案例包的划分和数据库,UI的设计. 包的划分 一个错误包的划分 为什么这个包是错误的: 如果对classifications更改就要影响payrolldatabase更改,还会迫使transactions更改,tansactions重新发布和编译测试就是不负责的,transactions没有共享封闭性,每个类都有自己变化的敏感,所以发布的频率非常高,是不合理的. 调整一下: 将具体类和具体类打包,抽象类和抽…
敏捷软件开发_UML  所看书籍是:敏捷软件开发_原则.模式与实践_C#版(美)马丁著,这本书写的非常棒,感谢作者.该归纳总结的过程按照我读的顺序写. UML  在建造桥梁,零件,自动化设备之前需要建模分析可行性,软件在编写之前也需要建立模型,看看类和逻辑的设计是否合理,这样的建模过程就是UML. 类图 类图就是来描述一个类本身或和其他类的调用关系. +public -private #protected 实现/泛化 集成 实现接口 组合 部分可以离开整体 聚合 部分不能离开整体 关联 持有对其…
第14章 使用UML 在探索UML的细节之前,我们应该先讲讲何时以及为何使用它.UML的误用和滥用已经对软件项目造成了太多的危害. 14.1 为什么建模 建模就是为了弄清楚某些东西是否可行.当模型比要构建的真实实体便宜很多时,我们就会使用模型来研究设计. 14.1.1 为什么构建软件模型 当我们有一些确定的东西需要测试,并且使用UML要比使用代码测试的代价更低一些是,就使用UML.比如,我有一个关于某个设计的想法.我想知道团队中的其他开发人员是否认为它是一个好的想法,于是,我就在白板上画一幅UM…
第12章 ISP:接口隔离原则 不应该强迫客户程序依赖并未使用的方法. 这个原则用来处理“胖”接口所存在的缺点.如果类的接口不是内敛的,就表示该类具有“胖”接口.换句话说,类的“胖”接口可以分解成多组方法.每一组方法都服务于一组不同的客户程序.这样,一些客户程序可以使用一组成员函数,而其他客户程序可以使用其他组的成员函数. ISP承认一些对象确实需要非内敛的接口,但是ISP建议客户不应该看到它们作为单一的类存在.相反,客户程序看到的应该是多个具有内敛接口的抽象基类. 12.1 接口污染 如果子类…
第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape…
第8章 SRP:单一职责原则 一个类应该只有一个发生变化的原因. 8.1 定义职责 在SRP中我们把职责定义为变化的原因.如果你想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.同时,我们很难注意到这一点.我们习惯于以组的形式去考虑职责.违反SRP的示例代码: public interface Modem { public void Dial(string pno); public void Hangup(); public void Send(char c); public ch…
1.0.0 Summary Tittle:[Scrum]-NO.40.EBook.1.Scrum.1.001-[敏捷软件开发:原则.模式与实践]- Scrum Style:DesignPattern Series:DesignPattern Since:2017-11-02 End:.... Total Hours:... Degree Of Diffculty:2 Degree Of Mastery:2 Practical Level:2 Desired Goal:2 Archieve Goa…
第8章 SRP:单一职责原则 一个类应该只有一个发生变化的原因. 8.1 定义职责 在SRP中我们把职责定义为变化的原因.如果你想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.同时,我们很难注意到这一点.我们习惯于以组的形式去考虑职责.违反SRP的示例代码: public interface Modem { public void Dial(string pno); public void Hangup(); public void Send(char c); public ch…