设计原则
1. 封装变化：
1). 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2). 这个原则的另一种思考方式：把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。
3). 这样的概念很简单，几乎是每个设计模式背后的精神所在。所有的模式都提供一套方法"系统中某部分改变不会影响其他部分"。
2. 针对接口编程，而不是针对实现编程。
1). 我们利用接口代表每个行为，比方说，FlyBehavior与QuackBehavior，而行为的每个实现都将实现其中一个接口。所以这次鸭子不会负责实现Flying与Quacking接口，反而由我们制造一组其他类专门实现
FlyBehavior与QuackBehavior，这就称为"行为"类。由行为类而不是Duck类来实现行为接口。
2). 这样的做法迥异于以往，以前的做法是：行为来自Duck超类的具体实现，或是继承某个接口并由子类自行实现而来。这两种做法都是依赖于"实现"，我们被实现绑的死死的，没办法更改行为(除非写更多代码)。
3). 在我们的芯设计中，鸭子的子类将使用接口(FlyBehavior与QuackBehavior)所表示的行为，所以实现的"实现"不会被绑死在鸭子的子类中。(话句话说，特定的具体行为编写在实现了FlyBehavior与QuackBehavior的类中)。
4). 针对接口编程的真正意思是针对超类型编程。针对接口编程的关键在于多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。"针对超类型编程"这句话，
可以更明确地说成"变量的声明类型应该是超类型"，通常一个抽象类或者是一个接口，如此，只要是具体实现比超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不必理会以后执行时的真正对象类型。
3. 多用组合，少用继承
使用组合建立系统具有很大的弹性，不仅可将算法簇封装成类，更可以"在运行时动态地改变行为"，只要组合的行为符合正确的接口标准即可。
4. 为了交互对象之间的松耦合性设计而努力
针对接口去调用，调用者和实际被调用者之间松耦合。
设计模式：
1. 策略模式：定义了算法簇，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
2. 观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
1). setChange()方法把changed标志设置为true。notityObservers()只会在changed标志为"true"时通知观察者。在通知观察者之后，把changed标志设回"fasle"。这样做有其必要性。setChanged()方法可以让你在更新
观察者时，有更多的弹性，你可以适当的通知观察者。在满足某些条件的情况下，再通知观察者。
原文：http://www.cnblogs.com/Jtianlin/p/5174259.html