
敏捷软件开发(原则模式与实践)
文章平均质量分 83
章节的小笔记
S火星人S
这个作者很懒,什么都没留下…
展开
-
敏捷开发笔记(第15章节)--FACADE模式和MEDIATOR模式
尊贵的符号外表下,隐藏着卑劣的梦想。本章中论述的两个模式有着共同的目的。它们都把某种策略(pocy)施加到另外一组对象上。FACADE模式从上面施加策略,而MEDIATOR模式则从下面施加策略。FACADE模式的使用是明显且受限的,而MEDIATOR模式的使用则是不明显且不受限制的。原创 2024-08-02 09:26:06 · 904 阅读 · 0 评论 -
敏捷开发笔记(第14章节)--TEMPLATE METHOD模式和STRATEGY模式:继承与委托
业精于勒”。一中国谚语早在20世纪90年代初期一也就是面向对象发展的初期一人们就非常看重继承这个概念。继承关系蕴涵的意义是非常深远的。使用继承我们可以基于差异编程(program by difference)!也就是说,对于某个满足了我们大部分需要的类,可以创建一Jerrilee M.Koheke个它的子类,并只改变其中我们不期望的部分。只是继承一个类,就可以重用该类的代码!通过继承,我们可以建立完整的软件结构分类,其中每一层都可以重用该层次以上的代码。这是一个美丽的新世界。原创 2024-08-01 09:36:55 · 670 阅读 · 0 评论 -
敏捷开发笔记(第13章节)--COMMAND模式和ACTIVE OBJECT模式
从严格的面向对象意义上来讲,这种做法是被强烈反对的一因为它具有功能分解的味道。然而,在这两个思维范式(paradigm)的碰撞处,有趣的事情发生了。这也许是真的,但是在实际的软件开发中,COM①MAND模式是非常有用的。该模式仅由一个具有惟一方法的接口组成,这似乎是荒谬的。有了这种结构,我们就可以在系统中传递Command对象并调用它们的do0方法,而无需明确地知道它们所代表的Command的种类。这会带来一些有趣的简化。在近几年记述过的所有设计模式中,我认为COMMAND模式是最简单、最优雅的模式之一。原创 2024-07-25 09:07:56 · 791 阅读 · 0 评论 -
敏捷开发笔记(第12章节)--接口隔离原则(ISP)
事实上,有一种特定的相关实践,可以使派生类无需实现这些方法,该实践的做法是把这些接口合并为一个基类,并在这个基类中提供接口中方法的退化实现。现在,考虑一个这样的实现,TimedDoor,.如果门开着的时间过长,它就会发出警报声。只有当DoorTimerAdapter对象所做的转换是必须的,或者不同的时候会需要不同的转换时,我才会选择图12.2中的方案而不是图12.3中的方案。该问题的答案基于这样的事实,就是一个对象的客户不是必须通过该对象的接口去访问它,也可以通过委托或者通过该对象的基类去访问它。原创 2024-07-20 11:07:05 · 1022 阅读 · 0 评论 -
敏捷开发笔记(第11章节)--依赖倒置原则(DIP)
所有结构良好的面向对象构架都具有清晰的层次定义,每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。这看起来似Policy Layer乎是正确的,然而它存在一个隐伏的错误特征,那Mechanism就是:Policy Layer对于其下一直到Utility Layer的改动Layer都是敏感的。每个较高层次都为它所需要的服务声明一个抽象接口,较低的层次实现了这些抽象接口,每个高层类都通过该抽象接口使用下一层,这样高层就不依赖于低层。请注意这里的倒置不仅仅是依赖关系的倒置,它也是接口所有权的倒置。原创 2024-07-17 09:14:00 · 876 阅读 · 0 评论 -
敏捷开发笔记(第10章节)--Liskov原则(LSP)
OCP背后的主要机制是抽象(abstraction)和多态(polymorphism)。在静态类型语言中,比如C++和Java,支持抽象和多态的关键机制之一是继承(inheritance)。正是使用了继承,我们才可以创建实现其基类(base class)中抽象方法的派生类。是什么设计规则在支配着这种特殊的继承用法呢?最佳的继承层次的特征又是什么呢?怎样的情况会使我们创建的类层次结构掉进不符合OCP的陷阱中去呢?这些正是Liskov替换原则(LSP)要解答的问题。原创 2024-07-08 09:13:06 · 787 阅读 · 0 评论 -
敏捷开发笔记(第9章节)--开放-封闭原则(OCP)
Ivar Jacobson曾说过,“任何系统在其生命周期中都会发生变化。如果我们期望开发出的系统不会再第一版后就被抛弃你就必须牢牢记住一点”。Bertrand Meyer在1988年提出著名的开发-封闭原则(The Open - closed Principle,简称OCP)为我们提供了指引。原创 2024-06-29 13:47:52 · 2310 阅读 · 1 评论 -
敏捷开发笔记(第8章节)--单一职责原则(SRP)
在SRP中,我们把职责定义为“变化的原因”,如果你能够想到多于一个的动机去改变一个了,那么这个类就具有多于一个的职责。有时,我们很难注意到这一点。我们习惯于以组的形式去考虑职责。图8.1.1.1。原创 2024-06-26 09:08:52 · 605 阅读 · 0 评论 -
敏捷开发笔记(第7章节)--什么是敏捷设计
在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的唯一软件文档,就是源代码清单。原创 2024-06-22 11:30:35 · 1989 阅读 · 0 评论 -
敏捷开发笔记(第6章节)--一次编程实践
设计和编程都是人的活动,忘记了这一点,将会失去一切。该章节都是代码示例,可自行进行阅读。原创 2024-06-17 09:07:57 · 283 阅读 · 0 评论 -
敏捷开发笔记(第5章节)--重构
本章讲述的是关于人的注意力的,阐述人民应该专注手边的工作并且确信自己正在尽全力,说明了使事物能够工作和使事物正确之间的区别,介绍了我们放入代码结构中的价值。重构的目的,是为了每天清洁你的代码。通过最小的努力就能够对我们的系统进行扩展和修改。要想具有这种能力,最重要的就是要保持代码的清洁。每一个软件模块都具有三项职责。第一个职责是它运行起来完成的功能。第二职责是它要应对变化。第三个职责是要和阅读它的人进行沟通。重构定义:在不改变代码外在的行为的前提下对代码做出修改,以改进代码的内部结构过程。原创 2024-06-11 08:46:53 · 334 阅读 · 0 评论 -
敏捷开发笔记(第4章节)--测试
测试套件运行起来越来越简单,就会越频繁的运行它们,测试运行得越多,就会越快的发现和那些测试的任务背离。如果有一天多次运行所有的测试,那么系统失效的时间就绝不会超过几分钟,这是一个合理的目标,我们决不允许系统倒退,一旦它工作在一个确定的级别上,就决不能让它倒退到一个稍低的级别。第一个也是最明显的一个影响,是程序中的每一项功能都有测试来验证它的操作的正确性。把程序设计为易于调用和可测试的,是非常重要的,为了易于调用和可测试,程序必须和周边环境解耦,这样首先编写测试迫使我们解除软件中的耦合。原创 2024-06-04 09:05:05 · 887 阅读 · 0 评论 -
敏捷开发笔记(第3章节)--计划
当你能够度量你所说的,并且能够用数字去表达它时,就表示你了解它;若你不能度量它,不能用数字去表达它,那么说明你的知识就是匮乏的、不能令人满意的。--凯尔文勋爵(英国物理学家)1883。原创 2024-05-28 09:01:24 · 768 阅读 · 0 评论 -
敏捷开发笔记(第2章节)--极限编程概述
极限编程(简称XP)是敏捷方法中最著名的一个。它由一系列简单却相互依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。本章节我们将简要的探讨一下这个整体。我们希望客户跟开发人员在一起紧密的工作,以便于彼此知晓对方所面临的问题,并共同去解决这些问题。谁是客户?XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。最好的情况是客户和开发人员在同一个房间中工作,次一点就是客户和开发人员之间的工作距离在100米内,距离越大,客户就越难成为真正的团队成员。原创 2024-05-14 08:38:26 · 869 阅读 · 0 评论 -
敏捷开发笔记(第1章节)--敏捷实践
敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法,这个方法关注的是可以达到团队目标的一些简单的技术。原创 2024-04-29 21:18:48 · 1027 阅读 · 0 评论