敏捷软件开发 问题&感想

看到第5张重构的时候，最终版的代码写的是真好。

优点：代码具有高可读性，基本就是让代码说话了，可以节省后面人阅读改代码的时间

缺点：但是我感觉是不是有点过度重构了，三行代码也要重新写个方法？本来开发时间有限，而且程序员设计好的类名和方法名的时候感觉是挺费时的一件事。我们是要开始写代码的时候就严格按照这种规范，还是可以先实现功能，然后后面进行重构呢，如果时间紧急又该如何？

在萌芽培训中我找到了答案：

1.不承认上线时间。先估算实现功能，最优设计等分别需要多长时间，如果pd数不够，可和leader和PM商量。

2.在紧急编码时，时间优于编码规范，可在下一个版本上线的时候把优化的代码带上去。

看到第6章的时候，感觉这本书说的有的也不太对，但又说不上错。

在开发的时候，是觉得可能会出现的那种情况而预先设计好呢，还是等到真正遇到那种情况才去改善（书中似乎认同后者，但我觉得前者也挺好啊）。

解答：看完第7章后，原来是这样的：我们不需要在一开始设计这个模块时就试图预测程序将如何变化。而是先已最简单的方法去编写，直到需求最终确实变化时，才修改模块设计，使之对该这种变化保持弹性。

记得在学校的时候，老师总是和我们说，做项目得拥抱需求、拥抱变化，让自己做出来的项目不惧怕需求的变更。那时的我在想，要拥抱变化就是要预先考虑到需求可能会有哪些变化，提前做好相应的设计。

但是在读了这本书之后，发现不是这样的了。

收获：

1.保持尽可能好的设计

敏捷开发人员不是每几周才清洁自己的设计，而是每天、每小时、每分钟都保持软件尽可能的干净、简单并且富有表现力。绝不会说“稍后我会回来修复它”，绝不让代码的腐化出现。

2.不预先做过多的设计

敏捷开发人员不会对一个庞大的需求预先设计应用哪些原则和设计模式。相反，那些原则和模式被应用在一次次的迭代中，力图使代码以及代码所表达的设计保持干净。

Principle
单一职责原则（SRP）：
就一个类而言，应该仅有一个引起它变化的原因。

问题：T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。

解决：遵守单一职责原则，将不同的职责封装到不同的类或模块中。

感想：

如果一个类承担的职责过多，就等于把这些职责耦合在一起，会影响复用性。软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离。

开放封闭原则（OCP）：
软件实体（类，模块，函数等等）应该是可以扩展的，但是不可修改的。

描述：“对扩展开放，对更改封闭”。

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。

对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。

感想：

要实现开放封闭原则，最重要的就是对频繁变化的部分进行抽象，但是不要对程序中的每个部分肆意地进行抽象。

Liskov替换原则（LSP）：
子类型必须能够替换掉它们的基类型

重要内容记录：对象的行为方式才是软件真正所关注的问题，LSP清晰的指出，OOD中IS-A关系是就行为方式而言的，行为方式是可以进行假设的，是客户程序所依赖的。那如何合理假设行为方式呢？

答：使用基于契约设计（Design By Contract，DBC），契约是通过为每个方法声明前置条件和后置条件来指定的。要使一个方法得以执行，前置条件必须为真。执行完毕后，该方法要保证后置条件为真。

派生类的前置条件和后置条件规则：

在重新声明派生类的例程中，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能使用相等的或者更弱的后置条件来替换原始的后置条件。（联想到了Java中，派生类子类的重载方法访问优先级应该不低于基类，这也是遵循后置条件规则吧）。

特别的：当派生类的方法中添加了基类不会抛出的异常，如果基类的使用者不期望这些异常，那么把他们添加到派生类的方法中就会导致不可替换性。此时要遵循LSP，要么必须改变使用者的期望，要么派生类就不该抛出这些异常。

结论：LSP是使OCP成为可能的主要原则之一。正是子类型的可替换性才使得使用基类型的模块在无需修改下就可以扩展。这种可替换性必须是可以隐式依赖的东西。因此，如果没有显示地强制基类类型的契约，那么代码就必须良好的并且明显地表达出这一点。术语“IS-A”的含义过于宽泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显示或者隐式的契约来定义。

自己理解：设计的时候一定要从行为上判断两个类之间是否具有is-a关系，如果不存在，将两个类的具有公共行为的方法提取到接口中，功能相似但是行为不同的，独自放入各自方法中，使得设计符合LSP。（P111）

问：是否子类重写了父类方法，那么通常就违法了LSP了？ 非也

依赖倒置原则（DIP）：
高层模块不应该依赖于底层模块，两者都应该依赖于抽象。

抽象不应该依赖于细节，细节应该依赖于抽象。

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。我们在项目中使用这个原则要遵循下面的规则：

每个类尽量都有接口或者抽象类，或者抽象类和接口两都具备

变量的表面类型尽量是接口或者抽象类

任何类都不应该从具体类派生

尽量不要覆写基类的方法
如果基类是一个抽象类，而这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会有一定的影响。

结合里氏替换原则使用
里氏替换原则：父类出现的地方子类就能出现。结合本章我们得出了一个通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系。抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要方法，在项目中，大家只要记住是”面向接口编程”就基本上是抓住了依赖倒置原则的核心了。

接口隔离原则（ISP）：
不应该强迫客户端依赖于它们不用的方法。

自己理解：接口隔离主要是不要让一个接口在含有许多方法的同时，被其他实体类依赖，被实体类依赖的接口不应该包含该实体类不需要的方法。