阅读《敏捷软件开发》札记
wjqtiger
这个作者很懒,什么都没留下…
展开
-
第22章 度量 中提到的
无法控制的东西就无法管理,无法测量的东西就无法控制。要想成为高效的软件工程师或者软件管理者,必须要能够控制软件开发的实践。如果没有测量它,无论如何都无法控制它。转载 2006-04-13 10:39:00 · 516 阅读 · 0 评论 -
第10章 Liskov替换原则 (LSP)
若对每个类型S的对象x,都存在一个类型T的对象y,使得在所有针对T编写的程序P中,用x替换y后,程序P行为功能不变,则S是T的字类型。转载 2006-06-07 10:48:00 · 706 阅读 · 0 评论 -
第9章 开放-封闭原则(OCP)
软件实体(类、模块、函数等等)应该是可以扩展的,但是不可以修改的。如果正确应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码了。转载 2006-06-05 14:32:00 · 546 阅读 · 0 评论 -
第9章 开放-封闭原则(OCP) 描述
1. 对于扩展是开放的(Open for extension)。 这意味着模块的行为是可以扩展的。换句话说,我们可以改变模块的功能。2. 对于更改是封闭的(Close for modification)。 对模块行为进行扩展时,不必改动模块的源代码或者二进制代码。转载 2006-06-05 14:47:00 · 784 阅读 · 0 评论 -
第5章 重构
每个软件模块都具有三项职责。第一项职责是它运行起来所完成的功能。第二项职责是它要应对变化。第三项职责是要和阅读它的人进行沟通。转载 2006-06-02 14:42:00 · 577 阅读 · 0 评论 -
第7章 什么是敏捷设计
设计的臭味----腐化软件的气味1. 僵化性(Rigidity):很难对系统进行改动,因为每个改动都会迫使对系统其他部分的改动。2. 脆弱性(Fragility):对系统的改动会导致系统中与改动没有关系的地方出现问题。3. 牢固性(Immobility):很难解开系统的纠结,使他成为可以在其他系统中重用的组件。4. 粘滞性(Viscosity):做正确的事情比做错误的事情要困难。5. 不必要的复杂转载 2006-06-05 10:37:00 · 621 阅读 · 0 评论 -
第28章 VISITOR模式中 EXTENSION OBJECT 模式
每个测试用例都是在还没有任何使之通过的代码的请况下编写的。一旦每个测试用例编写完成并失败了,就去编写使之通过的代码。代码决不会比使现有的测试用例通过所需要的更复杂。这样,代码就以微小增量的方式,从一个可工作的基点演化到另一个可工作的基点。转载 2006-04-18 16:54:00 · 834 阅读 · 0 评论 -
第26章 Proxy模式中提到
知道噩梦会出现在哪里是件好事。如果没有代理,噩梦就会遍布到应用程序代码的各个地方。转载 2006-04-17 14:02:00 · 561 阅读 · 0 评论 -
第28章 VISITOR模式中 Visitor模式的其他用途
如果一个应用程序中存在需要以多种不同方式进行解释的数据结构,就可以使用Visitor模式。在每个使用访问者的情况中,所使用的数据结构都独立于它的用途。可以创建新的访问者,可以更改现有的访问者,并且可以把所有访问者重新部署到安装地点而不会引起现有数据结构的重新编译和重新部署。转载 2006-04-18 16:47:00 · 787 阅读 · 0 评论 -
第22章 耦合和封装 中提到的
包之间的耦合可以使用UML语言的引出修饰(export adornment)来管理。转载 2006-04-13 10:30:00 · 476 阅读 · 0 评论 -
第25章 谁拥有这个接口 中提到
接口属于它的客户,而不是它的派生类。客户和接口之间的逻辑绑定关系要强于接口和它的派生类之间的逻辑绑定关系。逻辑关系的强度和实体关系的强度是不一致的。继承是一个比关联强得多的实体关系。转载 2006-04-14 10:18:00 · 536 阅读 · 0 评论 -
第22章 中应用公共封闭原则(CCP) 中提到的
底部是高度无依赖性和承担责任的包含通用部分的包,顶部是高度有依赖性和不承担责任的包含细节的包,这种结构是面向对象设计的标志转载 2006-04-13 10:23:00 · 686 阅读 · 0 评论 -
第10章 Liskov替换原则 基于契约的设计
在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件。转载 2006-06-07 10:56:00 · 747 阅读 · 0 评论