敏捷软件开发 之第二部分 敏捷设计
3月箴言
人的思想是了不起的，只要专注于某一项事业，就一定会做出使自己感到吃惊的成绩来。
开启第二部分：敏捷设计
一、拙劣设计的症状：
导致这些症状出现的原因：
1、最最最主要的原因就是代码界的段子：CV战士（我想大多数的代码搬运工是可以明白的，哈哈哈）
2、不断变化的需求（这个是无法避免的，需求一个持续变动的事实）
敏捷设计：是一个过程，而不是一个事件！它是一个持续的应用原则、模式以及实践来改变软件的结构和可读性的过程。它致力于保持系统设计在任何时候都尽可能的简单、干净以及富有变现力。
个人理解就是：接受变化，学习使用软件设计原则、模式，让程序健壮、易懂！（毕竟看代码的不是机器）
二、部分面向对象设计原则
三、单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。
如果一个类有多个引起它变化的原因，那么这个类就具有多个职责。
如果一个原因会引起几个职责同时变化，这种情况下不在拆分这几个职责；如果一个原因仅引起一个职责变化，另一个职责依赖于其他原因变化，这种情况需要将这两个职责分离以满足SRP原则。
关于示例，在之后的编写过程中完善再在本次文章中添加！
四、开放-封闭原则（OCP）：软件实体（类、模块、函数等）应该是可以扩展的，但是不可以修改的。
1、“对于扩展是开放的”：模块的行为可以扩展，也就是可以改变模块的功能。
2、“对于更改是封装的”：对模块的行为扩展时，不必改动模块的源代码或者二进制代码。
这一原则的关键是抽象。
模块可以操作一个抽象体，由于模块依赖于一个固定的抽象类，所以对于它的更改可以是关闭的，同时，通过这个抽象体派生，也可以扩展此模块的行为。
根据文中的示例个人理解是：
1、对于某一模块，创建一个抽象类（我个人理解为基类），包含基础属性和方法等；
2、具体的情况，创建该基类的一种子类，子类中覆写基类的属性、方法以满足该子类情况的实现；
3、如果新增了一种基类实现，就创建一个新的该基类的子类，用于扩展该模块，而不需要修改基类。
关于抽象的具体做法：当程序中出现频繁变化的那些部分做出抽象！
---------------------------我是分割线- ------------------------------------------------
---------------------------2019.3.23- ------------------------------------------------
---------------------------我是分割线- ------------------------------------------------
五、Liskoc替换原则（LSP）：子类型（subtype）必须能够替换他们的基类型（base type）。
对于这一原则理解的具体实现示例：OC语言中KVO的实现模式！当一个Obj注册addObserver方法的时候，在运行时会创建继承于obj的子类，在子类的setter方法中实现具体的其他实现，从而实现kvo的整体逻辑。
注意点：
1、有效性并非本质属性：一个模型，如果孤立地看，并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来表现；
2、IS-A是关于行为的：LSP清楚的指出，OOD中IS-A关系是就行为方式而言的，行为方式是可以进行合理假设的，是客户程序所依赖的；
3、基于契约设计：契约是通过为每个方法声明前置条件和后置条件来制定的。要使一个方法得以执行，前置条件必须为真。执行完毕之后，该方法的要保证后置条件为真。
关于子类、基类：
在重新声明派生类的例程（routine）时，只能使用相等或者更弱的前置条件的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的后置条件。
也就是说，当通过基类的接口使用对象时，用户只知道基类的前置条件和后置条件。因此，派生类对象不能期望这些用户遵从比基类更强的前置条件，同时派生类必须和基类所有后置条件一样。
（弱：如果X没有遵从Y的所有约束，那么X就比Y弱，X所遵从的新的约束的树木时无关紧要的）
4、在单元测试中指定契约。
本原则关键字：“可替换性”。
六、依赖倒置原则（DIP）：高层模块不应该依赖于底层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。
（对于本原则的理解尚有疑惑）
依赖于抽象：
1、任何变量都不应该持有一个指向具体类的指针或者引用
2、任何类都不应该从具体类派生
3、任何方法都不应该覆写它的任何基类中已经实现了的方法
个人理解：
一般情况下
ManagerObj 处理一个按钮的打开/关闭 操作
ButtonObj： open/close
依赖倒置的下的处理方式：
一个抽象的类 BtnObj，BtnObj类声明 open/close方法
ManagerObj 依赖于BtnObj
ButtonObj 继承自BtnObj，ButtonObj内部是open/close的具体实现
七、接口隔离原则（ISP）：不应该强迫客户依赖于他们不用的方法。
这个原则基于OC语言可以理解为代理，具体的可以参考系统关于UITableViewDelegate 和 UITableViewDataSourece的实现
目前关于原则的先到这里，这些原则还是要多理解，在实战中循序渐进的使用
PS：软件开发原则、模式学习实践之路任重道远，难难难，叹叹叹！
