随笔分类 -  敏捷开发

摘要：本文是翻译MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java(Mike Potel)文章的摘要.该文介绍了从MVC到MVP的思想演化过程.SmallTalk编程模型在该项目中,使用了MVC来实现GUI(... 阅读全文

摘要：包的设计.通过把类组织成package,可以在更高层次的抽象上理解设计.通过包来管理软件的开发和发布.由于类之间的相互依赖关系,包之间会产生依赖关系.包的依赖关系展示了APP的高层组织结构.粒度:内聚性."自顶向上"的将类划分到包中Reuse-Release Equivalence Priciple(REP).重用的粒度就是发布的粒度.重用类库时,我们要求author维护Code,同时在接口和功能改变时通知我们(同时我们有拒绝改变的权利).重用性必须基于包,可重用的包必须包含可重用的类.包中的所有类应该对于同一类用户来说都是可重用的.Common-Reuse Princip 阅读全文

摘要：ISP用来处理fat接口的缺点.如果类的接口不是内聚的,那么该类就具有fat接口.fat接口可以分解为多个组.每个组服务于不同的客户.ISP承认不需要内聚接口的对象.但是建议客户不应该看到它作为单一的类而存在.客户程序看到的应该是多个具有内聚接口的抽象基类.接口污染.分离客户就是分离接口.客户对接口施加的反作用力.考虑引起变化的作用力时,通常考虑的是接口的变化会怎么影响它的使用者.但有时候,迫使接口改变的,正是它的使用者.ISP:不应该强迫客户依赖于它们不使用的方法.这样会导致所有客户程序间的耦合.一个客户依赖于一个它不使用的方法的类.但是其他客户却要使用该方法.此时,当其它客户要求这个类改变 阅读全文

摘要：高层模块不应该依赖于底层模块，二者都应该依赖于抽象;细节应依赖于抽象.传统习惯中,高层模块依赖于底层模块,策略依赖于细节的结构.这是要定义子程序层次结构,该层次结构描述了高层模块如何调用底层模块.但是,这也就意味着,底层模块的更改会直接影响到高层模块.而APP的区别就是体现在这些高层模块中的.包含高层业务规则的模块应该优先并独立于包含细节的模块.通过子程序库来重用底层模块.我们更希望能够重用高层的策略设置模块.这也是Framework设计的核心.所以必须将高层独立于底层模块.倒置的接口所有权.底层实现了高层中声明并被高层调用的接口.这样高层可以在任何实现了该接口的环境中重用.有点短视的启发规则 阅读全文

摘要：OCP中,继承支持了抽象和多态特性.LSP:子类必须能够替换掉其基类.反例:使用if/else判断类型,以便选择针对特定类型的正确行为.有效性并非本质属性模型的有效性,只能通过它的客户程序来表现.在考虑一个特定设计是否合理时,必须要根据该设计的使用者所作出的合理假设来审视它.这些合理的假设常常就是单元测试中的assert.不要试图做所有的假设,而只是优先预测那些明显的对于LSP原则的违反情况,而在相关的脆弱性臭味出现时,才做其他的预测.IS-A是关于行为方式的.对象的行为方式才是软件所关注的.行为方式是可以进行合理假设的,是客户程序所依赖的.DBC:基于契约(Contract)设计.Class 阅读全文

摘要：对于僵化性的臭味,应用OCP原则之后,再进行同样的改动时,只需添加新代码,而不必改动已正常运行的代码.扩展模块行为的方式通常是修改模块的Code,不允许修改的模块常常被认为是具有固定的行为.Open:模块的行为是可以扩展的,即可以改变模块的功能.Close:对模块进行扩展时,不必改动DLL,Code,lib等.封闭创建于抽象的基础之上.关键是抽象.抽象基类: 固定,能够描述一组任意个可能行为的抽象体.派生类: 一组任意个可能的行为的表现.模块操作抽象体.所以模块的依赖是一个固定(对修改封闭的)的抽象体.然后,通过从这个抽象体派生,可以扩展此模块的行为.该结构的问题:很可能会需要在switch中 阅读全文

摘要：一个类应仅有一个引起它变化的原因.内聚性.每个Responsibility都是变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化当一个类耦合了多个职责时,一个职责的变化会消弱或抑制其他职责的能力.这种耦合导致了fragile的设计.职责.A reson for change.一个类负担的N个职责是否应该分开.取决于APP变化的方式.如果程序变化总是导致N个职责同时变化,那么不必.而反之需要解耦这些职责.变化的轴线仅当实际发生时才有意义,在没有征兆时应用SRP或者其他原则都是不明智的.解耦职责后,肯定会有一个kludge杂凑物来耦合这些职责,但是除了main外,都不需要知道它的存在,所以 阅读全文

摘要：Agility,指以微小增量的方式构建软件.全局视图和软件一起演化.每次迭代中,都使设计尽可能适合于当前系统,而不会花时间去预测未来的需求,更不会试图构建一些基础结构去支撑未来才需要的特性.更关注的是当前的系统.不进行预先设计,不需要成熟的初始设计.而保持设计尽可能的干净,简单.并使用单元测试和验收测试来保证.需求处在不停变化的状态之中,如果设计由于需求变化而退化,那么就不是敏捷的.在实现新需求时,应改进原有设计以让设计对新变化的同类变化具有弹性.而不是设法给设计打补丁.敏捷设计是一个过程,而不是事件.Design,源代码就是设计,而UML图示只是设计的附属物而不是设计本身.设计中的臭味常常是 阅读全文