敏捷软件开发 之第二部分 敏捷设计

3月箴言

人的思想是了不得的，只要专一于某一项事业，就必定会作出使本身感到吃惊的成绩来。—— 马克·吐温

开启第二部分：敏捷设计

1、拙劣设计的症状：

致使这些症状出现的缘由：

一、最最最主要的缘由就是代码界的段子：CV战士（我想大多数的代码搬运工是能够明白的，哈哈哈）

二、不断变化的需求（这个是没法避免的，需求一个持续变更的事实）

敏捷设计：是一个过程，而不是一个事件！它是一个持续的应用原则、模式以及实践来改变软件的结构和可读性的过程。它致力于保持系统设计在任什么时候候都尽量的简单、干净以及富有变现力。

我的理解就是：接受变化，学习使用软件设计原则、模式，让程序健壮、易懂！（毕竟看代码的不是机器）

2、部分面向对象设计原则

3、单一职责原则（SRP）：就一个类而言，应该仅有一个引发它变化的缘由。

若是一个类有多个引发它变化的缘由，那么这个类就具备多个职责。

若是一个缘由会引发几个职责同时变化，这种状况下不在拆分这几个职责；若是一个缘由仅引发一个职责变化，另外一个职责依赖于其余缘由变化，这种状况须要将这两个职责分离以知足SRP原则。

关于示例，在以后的编写过程当中完善再在本次文章中添加！

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

一、“对于扩展是开放的”：模块的行为能够扩展，也就是能够改变模块的功能。

二、“对于更改是封装的”：对模块的行为扩展时，没必要改动模块的源代码或者二进制代码。

这一原则的关键是抽象。

模块能够操做一个抽象体，因为模块依赖于一个固定的抽象类，因此对于它的更改能够是关闭的，同时，经过这个抽象体派生，也能够扩展此模块的行为。

根据文中的示例我的理解是：

一、对于某一模块，建立一个抽象类（我我的理解为基类），包含基础属性和方法等；

二、具体的状况，建立该基类的一种子类，子类中覆写基类的属性、方法以知足该子类状况的实现；

三、若是新增了一种基类实现，就建立一个新的该基类的子类，用于扩展该模块，而不须要修改基类。

关于抽象的具体作法：当程序中出现频繁变化的那些部分作出抽象！

---------------------------我是分割线- ------------------------------------------------

---------------------------2019.3.23- ------------------------------------------------

---------------------------我是分割线- ------------------------------------------------

 5、Liskoc替换原则（LSP）：子类型（subtype）必须可以替换他们的基类型（base type）。

 对于这一原则理解的具体实现示例：OC语言中KVO的实现模式！当一个Obj注册addObserver方法的时候，在运行时会建立继承于obj的子类，在子类的setter方法中实现具体的其余实现，从而实现kvo的总体逻辑。

注意点：

一、有效性并不是本质属性：一个模型，若是孤立地看，并不具备真正意义上的有效性。模型的有效性只能经过它的客户程序来表现；

二、IS-A是关于行为的：LSP清楚的指出，OOD中IS-A关系是就行为方式而言的，行为方式是能够进行合理假设的，是客户程序所依赖的；

三、基于契约设计：契约是经过为每一个方法声明前置条件和后置条件来制定的。要使一个方法得以执行，前置条件必须为真。执行完毕以后，该方法的要保证后置条件为真。

关于子类、基类：

在从新声明派生类的例程（routine）时，只能使用相等或者更弱的前置条件的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的后置条件。

也就是说，当经过基类的接口使用对象时，用户只知道基类的前置条件和后置条件。所以，派生类对象不能指望这些用户听从比基类更强的前置条件，同时派生类必须和基类全部后置条件同样。

（弱：若是X没有听从Y的全部约束，那么X就比Y弱，X所听从的新的约束的树木时可有可无的）

四、在单元测试中指定契约。

本原则关键字：“可替换性”。

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

（对于本原则的理解尚有疑惑）

依赖于抽象：

一、任何变量都不该该持有一个指向具体类的指针或者引用

二、任何类都不该该从具体类派生

三、任何方法都不该该覆写它的任何基类中已经实现了的方法

我的理解：

通常状况下

ManagerObj  处理一个按钮的打开/关闭 操做

ButtonObj： open/close 

依赖倒置的下的处理方式：

一个抽象的类 BtnObj，BtnObj类声明 open/close方法

ManagerObj 依赖于BtnObj

ButtonObj 继承自BtnObj，ButtonObj内部是open/close的具体实现

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

这个原则基于OC语言能够理解为代理，具体的能够参考系统关于UITableViewDelegate 和 UITableViewDataSourece的实现

 

目前关于原则的先到这里，这些原则仍是要多理解，在实战中按部就班的使用 

 

PS：软件开发原则、模式学习实践之路任重道远，难难难，叹叹叹！