设计模式 学习笔记

设计模式 第一章 Strategy pattern

设计原则 一

找出应用中可能变化之处，把他们独立出来，不要把他们和那些不需要变化的代码混在一起

原则二

针对接口编程，而不是针对实现编程

原则三

多用组合，少用继承

策略模式：定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

DUCK 方案！

设计模式 第二章 OBSERVER PATTERN

观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。在SWING等组件中大量使用了这种模式！JXTA估计也是！

设计原则四：

为了交互对象之间的松耦合设计而努力

原来JDK中的Observer有这么大的缺陷，JDK不完美啊！

宠辱不惊，看庭前花开花落；去留无意，望天空云卷云舒。

Weather Reporter 方案！

设计模式 第三章 decorate pattern

代码应如晚霞中的莲花一样的关闭（免于改变），如晨曦中的莲花一样开放（能够扩展），太TM哲学了 。

设计原则五：

设计应该对修改关闭，对扩展开放。

装饰着模式：动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

在JAVA.IO大量使用了decorate pattern，比如在对FILE的几种操作上的类上。设计模式给我打开了一道门！

设计模式 第四章 factory parttern

工厂方法模式：定义了一个创建对象的接口，但是由子类决定要实例化的是哪一个。工厂方法让类把实例化推迟到了子类。

ACTUALLY，没有发现工厂方法模式如何解决了对实现编程的问题，这和DUCK的例子中，对BEHAVIOR接口的实例化有是什么区别，为什么DUCK例子中就把这个行为定义为对实现编程，却又说明工厂模式可以解决这个问题。工厂模式似乎表现出来的，只是简单利用了DELEGATION和COMPOSITION的方式而已，看起来没有什么特别。

设计原则六：要依赖抽象，不要依赖具体类。（可以早就松耦合和易扩展和免于修改以前编写好的类），这个原则又叫依赖倒置原则（这个世界的定义有太多莫名其妙难以理解的ABB）：不能让高层组件依赖低层组件，而且两者都需依赖于抽象。

如下的几个指导方针，可以避免在OO设计中违反依赖倒置原则：

1.变量不可持有具体类的引用：如果使用NEW，就会持有具体类的引用，可以用工厂避开这样的做法。

2.不要让派生类生自具体类：如果生自具体类，就会依赖具体类，派生要来自一个抽象（接口或者抽象类）

3.不要覆盖基类中已实现的方法：如果覆盖基类中已实现的方法，那么基类就不是一个真正适合被继承的抽象。基类中已实现的方法，应该由所有的子类进行共享。