一、5大原则主要去除僵化性,脆弱性,牢固性,粘滞性,不必要的复杂性,不必要的重复
和晦涩性:
遵循敏捷实践去发现问题,应用设计原则去诊断问题,并且应用适当的设计模式去解决问题。
1. 单一职责原则(SRP):
指内聚性,一个模块的组成元素之间的功能相关性。有多余一个的动机去改变一个类,那么这个类就有多余1个的职责;
2. 开放封闭原则(OCP):
对于扩展是开放的,对于更改是封闭的;ocp背后的机制是抽象和多态;
3. Liskoo替换原则(LSP)
子类型必须能够替换掉他们的基类型,例子:长方形和正方形;
4. 依赖倒置原则(DIP)
高层模块不应该依赖于底层模块,二者依赖于抽象;
抽象不应该依赖于细节,细节应依赖于抽象。
高层(抽象)核心框架应该高度抽象;
5. 接口隔离原则(ISP)
不应该强迫客户依赖于他们不用的方法。
找出潜在的可以抽象的地方。对最有可能变化(根据业务)的地方使用模式,直到真正需要使用时才使用(重构)
二、熟悉以下模式以及应用场景:
1. Command模式:UNDO和activeObject模式
2. Strategy模式/template method模式:
继承和委托
3. Façade模式/Mediator模式:
Facade模式广泛而且可见,比如数据库访问层经常使用façade模式。从上面施加策略。
Mediator模式是隐含的,从下面施加策略。
4. Singleton模式/Monostate模式:
对于MonoState模式,所有的变量都是static的
5. NullObject模式
为了免除代码中到处存在的if(obj!=null)类似的代码。一般都在接口中实现一个内隐类(Null object)
6. Factory模式:如果具体类是高度可变的,应用该模式非常有用
7. Composite模式:针对树型结构时考虑
8. Observer模式:在增加新的观察对象时候可以无需更改被观察的对象。
9. Abstract server模式/adapter模式:
Adapter模式分为类和对象形式,接口都变了。例子:Modem
10. Extension Object模式
11. Bridge模式:对类层次有多个自由度的时候考虑
12. Proxy模式:
比如业务层和数据库实现分离,权限控制过程比较适合。
13. Visitor模式:
需要向类层次结构中添加新的方法,但是增加起来会很费劲或者会破坏设计。
14. Decorator模式:动态的插入/取消操作,继承原有接口。
15. State模式
三、需要进一步了解的部分:
1. 第19章,为何都以Transaction作为类。以及uml图的表示方式。
2. 第27章,气象站部分有时间再看看。
3. ets框架,以后有时间再看。