经过一年的努力，终于从外包公司逃出来了，在过去的一年里，主要是给华为做外包，外包的工作性质和工作中的点滴估计每一个做过外包的人都深有体会，体会到那种没有归宿感，没有自己的设计在里面，没有交际，没有沉淀，没有对代码的重构的机会等等。在外包工作到项目收尾的时候，偶尔的一次机会在资源共享里面看到了敏捷开发的资料，在读了《敏捷软件开发 原型 模式与实践》这本书后，感觉到自己怎么没有早点看到这本书呢？书中说了大量的敏捷开发相关的东西，再读了这本书后，敏捷开发的这种思想和精神给我的感触最深，敏捷意味着不断的追求完美，无限逼近客户 的需求，不断的修改，不断的重构自己的代码。把自己读书的一些笔记记录下来，分享一下,笔记中一些个人观点欢迎讨论。
一 面向对象的设计原则
1 类的单一职责原则 SRP
就一个类而言，应该只有一个引起他变化的原因。一个类相当于一个事物，一种关系等等，一个类的设计时，应该时刻意识到这个类是干什么的，完成什么功能。比如一个类描述了Book的一些属性和方法，但是当业务变化的时候，我们不能给书加上“buyBook”和“sellBook”或者“存储书本”记录的功能，因为这些功能是Book这个事物以外的另一个事物做的，当然加到Book里面也没有错，但是这样会影响后面的扩展和系统的升级。
也不是我们一开始就非常清楚这个的类的功能，可能我们刚开始设计类的时候没有把他设计成单一职责，但是我们在不断的编码过程，要时刻有意识的注意到类的单一职责原则
所有我觉得类的单一职责设计是一个持久的过程，而不是一开始就设计的非常到位。
2 开放-封闭原则 OCP
软件实体（类，模块，函数）应该可以扩展的，但是不可修改的
对应扩展开放，对应更改关闭。关键在于抽象：抽象类和接口。类和类之间的依赖尽量使用高层上的类，即抽象类或者接口，毕竟高层之间的谈话还是毕竟笼统、大范围的、不轻易的改变。
3 Liskov替换原则 LSP
子类型必须能够替换掉它们的基类型
替换性质：若对每一个类型S的对象o1，都存在一个类型T的对象o2，使得在所有针对T编写的程序P中用o1替换o2后，程序P的行为功能不变，则S是T的子类型。
这种替换主要体现在继承的性质上。
4 依赖倒置原则 DIP
抽象不应该依赖于细节，细节应该依赖于抽象。
a 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
b 抽象不应该依赖细节，细节应该依赖于抽象
抽象的东西往往是比较固定的，变化比较小的，在类之间 ，模块之间，类和模块之间的依赖应该通过抽象来进行依赖，而不是一个具体的实现类。
比如汽车和人之间的依赖，汽车依赖于人 ，人拥有汽车，不管什么人，都有可能拥有汽车，也不管什么汽车（奔驰，宝马）都有可能依赖于人（成为人的一个属性）。所以我们在建立人和汽车之间的关系是，使用抽象的人和抽象的汽车，而不是使用具体的人跟汽车产生关系，或者具体的汽车跟人产生关系。
可能有人会问，我们系统中关于人的东西没有那么多分类，顶多都是Chinese，那么你在设计的时候，可以暂时把Chinese作为抽象，如果在以后中，系统需求中出现了American，那么就需要把chinese进行重构，把person作为抽象
因为chinese已经不能统领到American这个类。只有往上抽象才能抽取出一个新的抽象类Person。所有我觉得这个也是在编码过程中根据需求进行不断的重构，不断的抽取新的抽象类，而不是一下子就抽取出一个大的东西，那样也不现实和简单
5 接口隔离原则 ISP
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构
分离客户就是分离接口
使用多重继承分离接口，使用委托分离接口，对客户进行分组，为不同的组而不是客户提供服务，“胖”类的消除每一个特 定的客户程序的接口仅仅声明它的特定客户或者客户组调用那些函数。
6 重用发布等价原则 REP
重用的粒度就是发布的粒度。将重用缩小道可发布即可运行的东西那么小，而不是把编写好的但是不用的方法或者类发布或者打包，然后重用。
7 共同封闭原则 CCP
包中的所有类对于同一类性质的变化应该是共同封闭的，一个变化若对一个包产生影响，则将对包中的所有类产生影响，而对于其他的包不造成任何影响
不应该一个变化引起多个包产生变化
8 共同重用原则 CRP
一个包中的所有类应该是共同重用的，如果重用了包中的一个类，那么就要重用包中的所有类。
9 无环依赖原则 ADP
在包的依赖关系图中不允许存在环。
10 稳定依赖原则 SDP
朝着稳定的方向进行依赖
11 稳定抽象原则 SAP
包的抽象程度应该和其稳定程度一致
1604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
