HeadFirst设计模式（中文版）-阅读笔记

 1.【Strategy】策略模式:
 * 定义了算法簇，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
 
 OO基础：
 * 抽象
 * 封装
 * 继承
 * 多态
 
 OO原则：
 * 封装变化
 * 多用组合，少用继承
 * 针对接口编程，而不是针对实现编程
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 知道OO基础，并不足以让你设计出良好的OO系统。
 * 良好的OO设计必须具备可复用、可扩充、可维护三个特性。
 * 模式可以让我们建造出具有良好OO设计质量的系统。
 * 模式被认为是历经验证的OO设计经验。
 * 模式不是代码，而是针对设计问题的通用的解决方案。你把他们应用到特定的应用中。
 * 模式不是被发明，而是被发现。
 * 大多数的模式和原则，都着眼于软件变化的主题。
 * 大多说的模式都允许系统局部改变独立于其他部分。
 * 我们常把系统中，会变化的部分抽出来封装。
 * 模式让开发人员之间有共享的语言，最大化沟通的价值。

2.【Observer】观察着模式（让你的对象知悉现况）:
 * 定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，依赖它的对象都会受到通知并自动更新。
 
 新增OO原则：
 * 为交互对象之间的松耦合设计而努力-------新原则，松耦合设计更具有弹性，更能应付变化。
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 观察者模式定义了对象之间的一对多关系。
 * 主题（也就是可观察者）用一个共同的接口来更新观察者。
 * 观察者和可观察者之间用松耦合方式结合（looscoupling），可观察者不知道观察者的细节，只知道观察者实现了观察者接口。
 * 使用此模式，你可以从被观察者处推（push）或拉（pull）数据（然而推的方式被认为更"正确"）。
 * 有多个观察者时，不可以依赖特定的通知次序。
 * Java有多种观察者模式的实现，包括了通用的java.util.Observable。
 * 要注意java.util.Observable实现所带来的一些问题。
 * 如果有必的话，可以实现自己的Observable，这并不难，不要害怕。
 * Swing使用大量观察者模式，许多GUI框架也是如此。
 * 此模式应被应用在许多地方，例如：JavaBeans、RMI。
 
3.【Decorator】装饰者模式（装饰对象）：
 * 动态地将责任附加到对象上。若要扩展功能，装饰者比继承提供了更有弹性的替代方案。
 
 新增OO原则：
 * 对扩展开放，对修改关闭。
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式。
 * 在我们的设计中，应允许行为可以被扩展，而无需修改现有的代码。
 * 组合和委托可用于在运行时动态地加上新的行为。
 * 除了继承，装饰者模式也可以让我们扩展行为。
 * 装饰者模式意味着一群装饰者类，这些类用来包装具体组件。
 * 装饰者类反映出被装饰的组件类型（事实上，他们具有相同的类型，都经过接口或继承实现）。
 * 装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的。
 * 你可以用无数个装饰者包装一个组件。
 * 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。
 * 装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂。
 
4.(1)【Factory】工厂方法模式（烘烤OO的精华）：
 * 定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
 
 新增OO原则：
 * 要依赖抽象，不要依赖具体类（依赖倒置原则）。
 
 避免在OO设计中违反依赖倒置原则的指导方针：(尽量达到这些原则，而不是随时都要遵守这些原则)
 * 变量不可以持有具体类的引用
 * 不要让类派生具体类
 * 不要覆盖基类中已实现的方法
 
  (2)【AbstractFactory】抽象工厂类：
 * 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
 
 加深理解：
 * 抽象工厂的方法通常以工厂方法的方式实现。
 * 抽象工厂的任务是定义一个负责创建一组产品的接口。在这个接口内的每个方法都负责创建一个具体产品，同时
   我们利用实现抽象工厂的子类来提供这些具体的做法。
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 所有的工厂都是用来封装对象的创建。
 * 简单工厂虽然不是真正的设计模式，但仍不失为一个简单的方法，可以将客户程序从具体类解耦。
 * 工厂方法使用继承：把对象的创建委托给子类，子类实现工厂方法来创建对象。
 * 抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中。
 * 所有的工厂模式都通过减少程序和具体类之间的依赖促进松耦合。
 * 工厂方法允许类将实例化延迟到子类进行。
 * 抽象工厂创建相关的对象家族，而不需要依赖他们的具体类。
 * 依赖倒置原则，指导避免依赖具体类型，而要尽量依赖抽象。
 * 工厂是很有威力的技巧，帮助我们针对抽象编程，而不要针对具体类编程。
 
5.【Singleton】单件模式（独一无二的对象）：
 * 确保一个类只有一个实例，并提供一个全局访问点。
 
 单件模式的3种实现方式：
 (1)如果getInstance()的性能对应用程序不是很关键，就什么都别做。
  * 同步getInstance()的方法既简单又有效。但是你必须知道，同步一个方法可能造成程序执行效率下降100倍。
    因此，如果将getInstance()得程序使用在频繁运行的地方，你可能就得重新考虑了。
     public class Singleton{
        private static Singleton uniqueInstance;
        
        private Singleton(){}
        
        public static synchronized Singleton getInstance(){
            if(uniqueInstance == null){
                uniqueInstance = new Singleton();
            }
            return uniqueInstance;
        }
     }
 (2)使用“急切”创建实例，而不用延迟实例化的做法。
  * 如果应用程序总是创建并使用单件实例，或者在创建和运行时方面的负担不太繁重，你可能想要急切创建此单件，如下所示：
    public class Singleton{
        private static Singleton uniqueInstance = new Singleton();
        
        private Singleton(){}
        
        public static Singleton getInstance(){
            return uniqueInstance;
        }
     }
 (3)使用“双重检查加锁”，在getInstance()中减少使用同步。
  * 利用双重检查加锁(double-checked locking)，首先检查实例是否已经创建了，如果尚未创建，“才”进行同步。
    这样以来，只有第一次会同步，这正是我们想要的。
    public class Singleton{
        private volatile static Singleton uniqueInstance;
        
        private Singleton(){}
        
        public static Singleton getInstance(){
            if(uniqueInstance == null){
                //检查实例，如果不存在就进入同步区域块。注意，只有第一次才彻底执行这里的代码
                synchronized(Singleton.class){
                    if(uniqueInstance == null){//进入区域块后，再检查一次，如果仍为null,才创建实例
                        uniqueInstance = new Singleton();
                    }
                }
            }
            return uniqueInstance;
        }
     }
    
   注：volatile关键词确保：当uniqueInstance变量被初始化成Singleton实例时，多个线程正确地处理uniqueInstance变量。
   * 如果性能是你关注的重点，那么这个做法可以帮你大大减少getInstance()的时间耗费。
   * 双重检查枷锁不适用于1.4及更早版本的Java！
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 单件模式确保程序中一个类最多只有一个实例。
 * 单件模式也提供访问这个实例的全局点。
 * 在Java中实现单件模式需要私有的构造器、一个静态方法和一个静态变量。
 * 确定在性能和资源上的限制，然后小心的选择适当的方案来实现单件，以解决多线程问题（我们必须认定所有的程序都是多线程的）。
 * 如果不是采用第五版的Java 2，双重检查枷锁实现会失效。
 * 小心，你如果使用多个类加载器，可能导致单件失效而产生多个实例。
 * 如果是用JVM1.2或之前的版本，你必须建立单件注册表，以免垃圾收集器将单件收回。
 
6.【Command】命令模式（封装调用）：
 * 将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 命令模式将发出请求的对象和执行请求的对象解耦
 * 在被解耦的两者之间是通过命令对象进行沟通的，命令对象封装了接受者和一个或一组动作。
 * 调用者通过调用命令对象的execute()发出请求，这会使得接受者的动作被调用。
 * 调用者可以接收命令当做参数，甚至在运行时动态地进行。
 * 命令可以撤销，做法是实现一个undo()方法来回到execute()被执行前的状态。
 * 宏命令是命令的一种简单的延伸，允许调用多个命令。宏方法可以支持撤销。
 * 实际操作时，很常见使用“聪明”命令对象，也就是直接实现了请求，而不是将工作委托给接收者。
 * 命令也可以用来实现日志和事务系统。
 
7.适配器与外观模式（随遇而安）：
 【Adapter】适配器模式：
 * 将一个类的接口，转换成客户期望的另一种接口。适配器让原本接口不兼容的类可以合作无间。
 
 【Facade】外观模式：
 * 提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
 
 新增OO原则：
 * 最少知识原则，只和你的密友谈话（只和朋友交谈）。

 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 当需要使用一个现有的类而其接口并不符合你的需要时，就是用适配器。
 * 当需要简化并统一一个很大的接口或者一群复杂接口时，使用外观。
 * 适配器改变接口以符合客户的期望。
 * 外观将客户从一个复杂的子系统中解耦。
 * 实现一个适配器可能需要一番功夫，也可能不费功夫，视目标接口的大小和复杂度而定。
 * 实现一个外观需要将子系统组合进外观中，然后将工作委托给子系统执行。
 * 适配器模式有两种形式：对象适配器和类适配器。类适配器需要用到多重继承。
 * 你可以为一个子系统实现一个以上的改观。
 * 适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；而外观将一群对象“包装”
   起来以简化接口。
 
8.【Template】模板方法模式（封装算法）：
 * 在一个方法中定义算法的框架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法的某些步骤。
 
 新增OO原则：
 * 别找我，我会找你（好莱坞原则）。

 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * “模板方法”定义了算法的步骤，把这些步骤的实现延迟到子类。
 * 模板方法模式为我们提供了一种代码复用的重要技巧。
 * 模板方法的抽象类可以定义具体方法、抽象方法和钩子。
 * 抽象方法由子类实现。
 * 钩子是一种方法，它在抽象类中不做事，或者制作默认的事情，子类可以选择要不要去覆盖它。
 * 为了防止子类改变模板方法中的算法，可以将模板方法声明为final。
 * 好莱坞原则告诉我们，将决策权放在高层模块中，以便决定如何及时地调用低层模块。
 * 你将在真实世界代码中看到模板方法模式的许多变体，不要期待它们全都是一眼就可以被你认出的。
 * 策略模式和模板方法模式都封装算法，一个用组合，一个用继承。
 * 工厂方法是模板方法的一种特殊版本。
 
9.迭代器与组合模式（管理良好的集合）：
 【Iterator Pattern】迭代器模式：
 * 提供一种方法顺序访问一个集合对象中的各个元素，而又不暴露其内部的表示。
 
 【Composite Pattern】组合模式：
 * 允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。
 
 新增OO原则：
 * 类应该只有一个改变的理由。

 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 迭代器允许访问聚合的元素，而不需要暴露它的内部结构。
 * 迭代器将遍历聚合的工作封装到一个对象中。
 * 当使用迭代器的时候，我们依赖聚合提供遍历。
 * 迭代器提供了一个通用的接口，让我们遍历聚合的项，当我们编码使用聚合的项时，就可以使用多态机制。
 * 我们应该努力让一个类只分配一个责任。
 * 组合模式提供一个结构，可以同时包括个别对象和组合对象。
 * 组合模式允许客户对个别对象以及组合对象一视同仁。
 * 组合结构内的任意对象称为组件，组件可以是组合，也可以是叶节点。
 * 在实现组合模式时，有许多设计上的折中，你要根据平衡透明性和安全性。
 
10.【State Pattern】状态模式（事务的状态）：
 * 允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 状态模式允许一个对象基于内部状态而拥有不同的行为。
 * 和程序状态机（PSM）不同，状态模式用类代表状态。
 * Context会将行为委托给当前状态对象。
 * 通过将每个状态封装进一个类，我们将以后需要做的任何改变局部化了。
 * 状态模式和策略模式有相同的类图，但他们的意图不同。
 * 策略模式通常会用行为或算法来配置Context类。
 * 状态模式允许Context随着状态的改变而改变行为。
 * 状态转换可以有State类或Context类控制。
 * 使用状态模式通常会导致设计中类的数目大量增加。
 * 状态类可以被多个Context实例共享。
 
11.【Proxy Pattern】代理模式（控制对象的访问）：
 * 为另一个对象提供一个替身或占位符以控制对这个对象的访问。

 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 代理模式为另一个对象提供代表，以便控制客户对对象的访问，管理访问的方式有许多种。
 * 远程代理管理客户和远程对象之间的交互。
 * 虚拟代理控制访问实例化开销大的对象。
 * 保护代理基于调用者控制对象方法的访问。
 * 代理模式有许多变体，例如：缓存代理、同步代理、防火墙代理和写入时复制代理。
 * 代理在结构上类似装饰者，但是目的不同。
 * 装饰者模式为对象加上行为，而代理则是控制访问。
 * Java内置的代理支持，可以根据需要建立动态代理，并将所有调用分配到所选的处理器。
 * 就和其他的包装者（wrapper）一样，代理会造成你的设计中类的数目增加。
 
12.【Compound Pattern】复合模式（模式的模式）：
 * 复合模式结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * MVC是复合模式，结合观察者模式、策略模式和组合模式。
 * 模型使用观察者模式，以便观察者更新，同时保持两者之间解耦。
 * 控制器是视图的策略，视图可以使用不同的控制器实现，得到不同的行为。
 * 视图使用组合模式实现用户界面，用户界面通常组合了嵌套的组件，像面板、框架和按钮。
 * 这些模式携手合作把MVC模型的三层解耦，这样可以保持设计干净又有弹性。
 * 适配器模式用来将新的模型适配成已有的视图和控制器。
 * Model2是MVC在web上的应用。
 * 在Model2中控制器实现成Servlet，而JSP/Html实现视图。
 
13.与设计模式相处（真实世界中的模式）：
 【模式】：模式是在某情景(Context)下，针对某问题的某种解决方案。
 
 用模式思考：
 * 保持简单(Keep It Simple/KISS)。
 * 设计模式非万灵丹：事实上，连什么丹都算不上。
 * 你知道何时需要模式。
 * 重构的时间就是模式的时间！
 * 拿掉你所不需要的，不要害怕将一个设计模式从你的设计中删除。
 * 如果你现在不需要，就别做。
 
 共享词汇的五种方式：
 * 在设计会议中。
 * 和其他开发人员。
 * 在架构文档中。
 * 在代码注释及命名习惯上。
 * 将志同道合的开发人员集合在一起。
 
 【反模式】：告诉你如何采用一个不好的解决方案解决一个问题。
 
 OO原则汇总：
 * 封装变化
 * 多用组合，少用继承
 * 针对接口编程，而不是针对实现编程
 * 为交互对象之间的松耦合设计而努力
 * 类应该对扩展开放，对修改关闭
 * 依赖抽象，不要依赖具体类
 * 只和朋友交谈
 * 别找我，我会找你
 * 类应该只有一个改变的理由
 
 本章要点：>>>>>>>>>>>>>>>>>>>>>>>
 * 让设计模式自然而然的出现在你的设计中，而不是为了使用而使用。
 * 设计模式并非僵化的教条；你可以根据自己的需要采用或调整。
 * 总是使用满足需要的最简单解决方案，不管它用不用模式。
 * 学习设计模式的类目，可以帮你自己熟悉这些模式以及他们之间的关系。
 * 模式的分类（或类目）是将模式分成不同的族群，    如果这么做对你有帮助，就采用吧!
 * 你必须相当专注才能成为一个模式的作家：这需要时间，也需要耐心，同时还必须乐意做大量的精华工作。
 * 请牢记：你所需到的大多数模式都是现有模式的变体，而非新的模式。
 * 模式能给你带来的最大的好处之一是：让你的团队拥有共享词汇。
 * 任何社群都有自己行话，模式社群也是如此。别让这些行话绊着，在读完这本书后，你已经能够应用大部分的行话了。