设计模式（Headfirst）学习

设计原则：
    找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
    系统中某部分改变不会影响其他部分。
    针对接口（也是超类型）编程，而不是针对实现编程。
   
    接口不是万能的，本质的东西要继承

    多用组合，少用继承。
   
    为了交互对象之间的松耦合设计而努力。

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

    依赖抽象，不要依赖具体类。
   
    解决多线程的方法：
        同步getInstance()
        急切实例化
        双重检查加锁

    最少知识原则：只和你的密友谈话。

    好莱坞原则：别调用（打电话给）我们，我们会调用（打电话给）你。

    设计原则：一个类应该只有一个引起变化的原因。
   
     类应该只有一个改变的理由。

    远程代理控制访问远程对象。
   
    虚拟代理控制访问创建开销大的资源。

    保护代理基于权限控制对资源的访问。


    策略模式： 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用于算法的客户。
    观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
    装饰者模式：动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
    （不能过渡使用）
    工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
    单例模式：确保一个类只有一个实例，并提供一个全局访问点。
    适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
    外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
    模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法的某些步骤。
    迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。
    组合模式 允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让用户以一致的方式处理个别对象以及对象组合。
    状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
    代理模式：为另一个对象提供一个替身或占位符以控制对这个对象的访问。

背景  Joe上班的公司做了一套相当成功的模拟鸭子游戏，SimUDuck.游戏中会出现各种鸭子，一边游泳戏水，一边呱呱叫，此系统的内部设计使用了标准的OO技术，设计了一个鸭子超类，并让各种鸭子继承此超类。

        Duck
        quack();
        swim();
        display;
        //鸭子的其他方法
    所有的鸭子都会呱呱叫（quack），也会游泳（Swim).所以此部分由超类来实现该部分代码。
    每个鸭子子类型负责实现自己的display()行为，用以在屏幕上显示其外观。

策略模式
    问题1 公司的竞争压力加剧。大家经过头脑风暴后认为要为游戏中的鸭子增加飞fly()的行为来增加卖点。
可是再为鸭子超类增加了fly()方法后。
可是在父类中加入该方法后导致了橡皮的鸭子也会飞。我们不得不修改原来的橡皮鸭子，让其覆盖父类的行为。
以后我们将会面临越来越多的修改。
如果以后我加入了木头的诱饵鸭，它不会飞也不会叫。我们要覆盖更多的没有用的方法。

利用继承来提供Duck的行为，这会导致：
    代码在多个子类中重复。
    运行时的行为不容易改变。
    改变会牵一发动全身，造成其他鸭子不想要的改变。
    鸭子不能同时又飞又叫。

解决方案1：利用接口Flyable和Auackable。
    解决了又飞又叫的木头鸭。

    问题2 实现代码在多个子类中重复。代码无法复用。

观察者模式
    问题1 要建立一个气象监测的应用。此系统的三个部分是：气象站、WeatherData对象（追踪来自气象站的数据，并更新布告板）和布告板（显示目前天气状况给用户看）。WeatherData对象知道如何跟物理气象站联系，以取得更新的数据。WeatherData对象会随即更新三个布告板的显示：目前状况（温度、湿度、气压）
、气象统计和天气预报。

class    WeatherData
{
getTemperature();
getHumidity();
getPressure();
/*
*一旦气象数据更新，此方法将会被调用
*/
measure-mentsChanged();
}

装饰器模式
我们要做一个饮料器程序。首先为该饮料器中选择某种饮料，然后再为饮料中添加糖，牛奶，冰块，橘汁，摩卡，冰糖等调料。
如果我们选择一个饮料基类Beverage。

class Beverage{
    description;
    getDescription();
    cost();
}

如果我们要一杯加牛奶，冰块，摩卡和冰糖的饮料。我们就创建一个这样的类，那客户的选择是多种多样的。我们会为类爆炸而烦恼。
还有一种解决办法是 hasMilk();但是这样不利于类的扩展。一旦我们有新的变化，我们就要修改基类。而且以后开发出新饮料，某些调料也可能不适合。而且顾客可能想要双倍的摩卡咖啡。

最终我们选择用装饰器模式。我感觉这个翻译成包装模式更贴切。