Head First 设计模式（中文版）

按有用程度 按页码先后 最新笔记

• 

  第一章 策略模式

  archangelys

  针对接口（Interface）编程而不是针对实现（method）编程，这句话很重要！ 少用继承，多用组合。在类中包含接口对象，调用接口对象的方法，接口对象可以被灵活的设置，称之为不同的策略。 (更多)

  针对接口（Interface）编程而不是针对实现（method）编程，这句话很重要！

  少用继承，多用组合。在类中包含接口对象，调用接口对象的方法，接口对象可以被灵活的设置，称之为不同的策略。 (收起)

  2012-02-09 19:29:32   回应

  收藏

  推荐
• 

  全书

  柒夏 (人生得意须尽欢)

  设计原则：找出应用中可能需要变化之处，把它们独立出来，不需要和那些不需要变化的代码混在一起。 注解：如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。 设计原则：针对接口编程，而不是针对实现编程。 注解：“针对接口编程”真正的意思是... (更多)

  设计原则：找出应用中可能需要变化之处，把它们独立出来，不需要和那些不需要变化的代码混在一起。

  注解：如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。

  设计原则：针对接口编程，而不是针对实现编程。

  注解：“针对接口编程”真正的意思是“针对超类型编程”。“针对超类型编程”这句话，可以更明确地说成，变量的声明类型应该是超类型，通常是一个抽象类或是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型。

  设计原则：多用组合，少用继承。

  注解：使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以在运行时动态地改变行为，只要组合的行为对象符合正确的接口标准即可。

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

  备注：变化的部分提取出来，定义接口，接口有不同的实现（算法族）。类具有接口成员，实例化为具体的算法对象，然后对其进行调用。

  ====================================================================

  观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

  备注：观察者需要向被观察者注册，这样被观察者存有所有观察者组成的集合，当状态改变时，依次通知观察者。观察者与被观察者之间不用知道对方细节。

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

  注解：当两个对象之间松耦合，它们依然可以交互，但是不太清楚彼此的细节。松耦合的设计能让我们建立有弹性的OO系统，能够应对变化，因为对象之间的互相依赖降到了最低。

  ====================================================================

  设计原则：类应该对扩展开放，对修改关闭。

  注解：我们的目标是允许类扩展，在不修改现有代码的情况下，就可搭配新的行为。这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。遵循开放-关闭原则，通常会引入新的抽象层次，增加代码的复杂度，没有必要把设计的每个部分都这么设计。把注意力集中在设计中最有可能改变的地方，然后应用开放-关闭原则。

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

  备注：装饰者和被装饰者必须是一样的类型，有共同的超类。装饰者存有共同超类成员，来组合被装饰者。可以嵌套装饰，即装饰者也可以成为其他装饰者的被装饰者。行为来自装饰者本身和被装饰者组件，在任何时候都可以实现新的装饰者增加新的行为，装饰者可以在被装饰者前面或后面加上自己的行为，甚至取代被装饰者的行为，而达到特定的目的。装饰者模式也有缺点，那就是设计中有大量的小类。

  ====================================================================

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

  备注：超类（抽象创建者类）定义创建对象（产品类）的抽象工厂方法，由子类（具体创建者类）实现此方法来处理对象（产品类）的实例化，将超类的代码与创建具体对象的代码分开（松耦合原则）。超类代码通常包含依赖于抽象产品的方法，这些抽象产品由子类制造，超类不需了解在制造哪种具体产品。所有产品必须实现共同接口，这样使用这些产品的类就可以引用接口而不是具体类。

  设计原则：要依赖抽象，不要依赖具体类。

  注解：不能让高层组件依赖底层组件，而且不管高层或底层组件，“两者”都应该依赖于抽象。指导方针：1.变量不可以持有具体类的引用（用工厂来避开new具体类）；2.不要让类派生自具体类（请派生自抽象，即接口或抽象类）；3.不要覆盖基类中已实现的方法。

  抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

  备注：抽象工厂定义一个接口用来生产产品，具体工厂实现此接口，创建不同产品。客户只需涉及抽象工厂，运行时使用实例工厂。

  工厂方法：采用继承的方式创建对象，将客户代码从需要实例化的具体类中解耦。

  抽象工厂：采用对象组合的方式创建对象，可以创建产品家族，也可以让制造的相关产品集合起来。也可将客户代码从需要实例化的具体类中解耦。抽象工厂创建产品的方法通常以工厂方法实现。

  ====================================================================

  单件模式：确保一个类只有一个实例，并提供一个全局访问点。

  备注：类中持有私有构造器，一个静态变量uniqueInstance存储实例化对象，还有一个静态的方法getInstance返回实例化对象（全局访问点）。单件类一般用的机会不多，继承单件类要处理更多的问题。用延迟实例化的做法，多线程可能导致单件模式出现多个实例：1.可用synchronized同步getInstance方法，但这样影响效率；2.在静态变量中初始化实例，不延迟创建实例，可保证线程安全；3.getInstance双重检查，不存在实例才进入同步区，不存在实例才创建实例。使用volatile关键字修饰uniqueInstance。

  ====================================================================

  命令模式：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销操作。

  备注：所有命令对象实现包含一个方法的命令接口，命令对象持有接收者，该方法调用接收者的动作。调用者持有命令对象，只用调用命令对象的该方法，即可完成命令。客户端创建接收者、命令对象、调用者，向命令对象中set接收者，向调用者中set命令对象，然后执行调用者的方法完成命令。

  ====================================================================

  适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本借口不兼容的类可以合作无间。

  备注：适配器实现想转换成的类型接口，取得需要适配的对象引用，实现接口中的所有方法。

  外观模式：提供了一个统一的接口，用来访问子系统中的一群接口，外观定义了一个高层接口，让子系统更容易使用。

  备注：外观持有子系统对象，外观中实现方法，使用子系统处理相应操作。

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

  注解：当你正在设计一个系统，不管是任何对象，你都需要注意它所交互的类有哪些，并注意它和这些类是如何交互的。不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。在对象的方法内，只应该调用属于以下范围的方法：1.该对象本身；2.被当做方法的参数而传递进来的对象；3.此方法创建或实例化的任何对象；4.对象的任何组件。上述说明，某对象是调用其他的方法的返回结果，不要调用该对象的方法。该原则减少对象依赖，减少软件维护成本，但缺点是导致更多的“包装”类被制造出来，可能会导致复杂度和开发时间的增加，降低运行时的性能。

  ====================================================================

  模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

  备注：模板方法中定义了一组步骤方法，任何步骤方法都可以是抽象的，由子类负责实现。其中可以有空实现方法，称为“钩子”，让子类有能力对算法的不同点进行挂钩。模板方法被声明为final，以免子类改变算法。

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

  注解：防止“依赖腐败”，允许底层组件挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些底层组件。

  未完待续... (收起)

  2012-01-11 16:07:30   回应

  收藏

  推荐
• 

  第80页

  要多响亮

  装饰者模式：动态地将责任附加到对象上，想要扩展功能，装饰者提供有别于继承的另一种选择 设计原则： 1. 类应该对扩展开放，对修改关闭 这个模式不是很理解，感觉就是通过继承的方式，增加对象的功能。 但是是这样的么？ 留爪爪，以待思考。 (更多)

  装饰者模式：动态地将责任附加到对象上，想要扩展功能，装饰者提供有别于继承的另一种选择

  设计原则：

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

  这个模式不是很理解，感觉就是通过继承的方式，增加对象的功能。

  但是是这样的么？

  留爪爪，以待思考。 (收起)

  2011-12-29 14:43:17   回应

  收藏

  推荐

• 

  第1页

  Nix (坚持学习技术，从Hadoop开始！！)

  曾经粗略的翻看过其中的一些模式，但是当初是为了应付面试，校招过了之后也就没有看过。对其中的singleton pattern、factory pattern、strategy pattern、proxy pattern几个模式印象深刻。但是感觉这些在工作中都用不到，就不太想看了。直到前几天看到了一个strategy pattern的示例，感觉设计模式对于程序员来说就像音乐对于我们所有人来说一样，真的就是艺术。写这段笔记其实不合适，因为我都还没有开始看，但是对程序设计艺术的.. (更多)

  曾经粗略的翻看过其中的一些模式，但是当初是为了应付面试，校招过了之后也就没有看过。对其中的singleton pattern、factory pattern、strategy pattern、proxy pattern几个模式印象深刻。但是感觉这些在工作中都用不到，就不太想看了。直到前几天看到了一个strategy pattern的示例，感觉设计模式对于程序员来说就像音乐对于我们所有人来说一样，真的就是艺术。写这段笔记其实不合适，因为我都还没有开始看，但是对程序设计艺术的追求的种子已经发芽了，开始吧！！！ (收起)

  2011-04-05 14:44:23   回应

  收藏

  推荐
• 

  第1页

  X.Jing

  第一章:　策略模式　 继承不是唯一的扩展方式，　把不变的内容和要变的分离，　为接口编程而不为实现编程，　把可变的部分用接口来处理，　委托其它类去处理． (更多)

  第一章:　策略模式　

  继承不是唯一的扩展方式，　把不变的内容和要变的分离，　为接口编程而不为实现编程，　把可变的部分用接口来处理，　委托其它类去处理． (收起)

  2011-10-15 23:29:03   回应

  收藏

  推荐
• 

  第12页

  要多响亮

  针对接口编程真正的意思是“针对超类型编程”，关键就在于利用多态。 继承的作用在与代码复用。 对于重复通用的代码可以采用父类实现，子类继承。 设计原则： 1. 找出应用中可能需要变化之处 2. 针对接口编程，而不是针对实现编程 3. 多用组合，少用继承 策略模式 定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户 (更多)

  针对接口编程真正的意思是“针对超类型编程”，关键就在于利用多态。

  继承的作用在与代码复用。

  对于重复通用的代码可以采用父类实现，子类继承。

  设计原则：

  1. 找出应用中可能需要变化之处

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

  3. 多用组合，少用继承

  策略模式

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

  2011-12-27 13:46:14   回应

  收藏

  推荐

• 

  第一章 策略模式

  archangelys

  针对接口（Interface）编程而不是针对实现（method）编程，这句话很重要！ 少用继承，多用组合。在类中包含接口对象，调用接口对象的方法，接口对象可以被灵活的设置，称之为不同的策略。 (更多)

  针对接口（Interface）编程而不是针对实现（method）编程，这句话很重要！

  少用继承，多用组合。在类中包含接口对象，调用接口对象的方法，接口对象可以被灵活的设置，称之为不同的策略。 (收起)

  2012-02-09 19:29:32   回应

  收藏

  推荐
• 

  全书

  柒夏 (人生得意须尽欢)

  设计原则：找出应用中可能需要变化之处，把它们独立出来，不需要和那些不需要变化的代码混在一起。 注解：如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。 设计原则：针对接口编程，而不是针对实现编程。 注解：“针对接口编程”真正的意思是... (更多)

  设计原则：找出应用中可能需要变化之处，把它们独立出来，不需要和那些不需要变化的代码混在一起。

  注解：如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。

  设计原则：针对接口编程，而不是针对实现编程。

  注解：“针对接口编程”真正的意思是“针对超类型编程”。“针对超类型编程”这句话，可以更明确地说成，变量的声明类型应该是超类型，通常是一个抽象类或是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型。

  设计原则：多用组合，少用继承。

  注解：使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以在运行时动态地改变行为，只要组合的行为对象符合正确的接口标准即可。

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

  备注：变化的部分提取出来，定义接口，接口有不同的实现（算法族）。类具有接口成员，实例化为具体的算法对象，然后对其进行调用。

  ====================================================================

  观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

  备注：观察者需要向被观察者注册，这样被观察者存有所有观察者组成的集合，当状态改变时，依次通知观察者。观察者与被观察者之间不用知道对方细节。

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

  注解：当两个对象之间松耦合，它们依然可以交互，但是不太清楚彼此的细节。松耦合的设计能让我们建立有弹性的OO系统，能够应对变化，因为对象之间的互相依赖降到了最低。

  ====================================================================

  设计原则：类应该对扩展开放，对修改关闭。

  注解：我们的目标是允许类扩展，在不修改现有代码的情况下，就可搭配新的行为。这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。遵循开放-关闭原则，通常会引入新的抽象层次，增加代码的复杂度，没有必要把设计的每个部分都这么设计。把注意力集中在设计中最有可能改变的地方，然后应用开放-关闭原则。

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

  备注：装饰者和被装饰者必须是一样的类型，有共同的超类。装饰者存有共同超类成员，来组合被装饰者。可以嵌套装饰，即装饰者也可以成为其他装饰者的被装饰者。行为来自装饰者本身和被装饰者组件，在任何时候都可以实现新的装饰者增加新的行为，装饰者可以在被装饰者前面或后面加上自己的行为，甚至取代被装饰者的行为，而达到特定的目的。装饰者模式也有缺点，那就是设计中有大量的小类。

  ====================================================================

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

  备注：超类（抽象创建者类）定义创建对象（产品类）的抽象工厂方法，由子类（具体创建者类）实现此方法来处理对象（产品类）的实例化，将超类的代码与创建具体对象的代码分开（松耦合原则）。超类代码通常包含依赖于抽象产品的方法，这些抽象产品由子类制造，超类不需了解在制造哪种具体产品。所有产品必须实现共同接口，这样使用这些产品的类就可以引用接口而不是具体类。

  设计原则：要依赖抽象，不要依赖具体类。

  注解：不能让高层组件依赖底层组件，而且不管高层或底层组件，“两者”都应该依赖于抽象。指导方针：1.变量不可以持有具体类的引用（用工厂来避开new具体类）；2.不要让类派生自具体类（请派生自抽象，即接口或抽象类）；3.不要覆盖基类中已实现的方法。

  抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

  备注：抽象工厂定义一个接口用来生产产品，具体工厂实现此接口，创建不同产品。客户只需涉及抽象工厂，运行时使用实例工厂。

  工厂方法：采用继承的方式创建对象，将客户代码从需要实例化的具体类中解耦。

  抽象工厂：采用对象组合的方式创建对象，可以创建产品家族，也可以让制造的相关产品集合起来。也可将客户代码从需要实例化的具体类中解耦。抽象工厂创建产品的方法通常以工厂方法实现。

  ====================================================================

  单件模式：确保一个类只有一个实例，并提供一个全局访问点。

  备注：类中持有私有构造器，一个静态变量uniqueInstance存储实例化对象，还有一个静态的方法getInstance返回实例化对象（全局访问点）。单件类一般用的机会不多，继承单件类要处理更多的问题。用延迟实例化的做法，多线程可能导致单件模式出现多个实例：1.可用synchronized同步getInstance方法，但这样影响效率；2.在静态变量中初始化实例，不延迟创建实例，可保证线程安全；3.getInstance双重检查，不存在实例才进入同步区，不存在实例才创建实例。使用volatile关键字修饰uniqueInstance。

  ====================================================================

  命令模式：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销操作。

  备注：所有命令对象实现包含一个方法的命令接口，命令对象持有接收者，该方法调用接收者的动作。调用者持有命令对象，只用调用命令对象的该方法，即可完成命令。客户端创建接收者、命令对象、调用者，向命令对象中set接收者，向调用者中set命令对象，然后执行调用者的方法完成命令。

  ====================================================================

  适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本借口不兼容的类可以合作无间。

  备注：适配器实现想转换成的类型接口，取得需要适配的对象引用，实现接口中的所有方法。

  外观模式：提供了一个统一的接口，用来访问子系统中的一群接口，外观定义了一个高层接口，让子系统更容易使用。

  备注：外观持有子系统对象，外观中实现方法，使用子系统处理相应操作。

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

  注解：当你正在设计一个系统，不管是任何对象，你都需要注意它所交互的类有哪些，并注意它和这些类是如何交互的。不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。在对象的方法内，只应该调用属于以下范围的方法：1.该对象本身；2.被当做方法的参数而传递进来的对象；3.此方法创建或实例化的任何对象；4.对象的任何组件。上述说明，某对象是调用其他的方法的返回结果，不要调用该对象的方法。该原则减少对象依赖，减少软件维护成本，但缺点是导致更多的“包装”类被制造出来，可能会导致复杂度和开发时间的增加，降低运行时的性能。

  ====================================================================

  模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

  备注：模板方法中定义了一组步骤方法，任何步骤方法都可以是抽象的，由子类负责实现。其中可以有空实现方法，称为“钩子”，让子类有能力对算法的不同点进行挂钩。模板方法被声明为final，以免子类改变算法。

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

  注解：防止“依赖腐败”，允许底层组件挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些底层组件。

  未完待续... (收起)

  2012-01-11 16:07:30   回应

  收藏

  推荐
• 

  第80页

  要多响亮

  装饰者模式：动态地将责任附加到对象上，想要扩展功能，装饰者提供有别于继承的另一种选择 设计原则： 1. 类应该对扩展开放，对修改关闭 这个模式不是很理解，感觉就是通过继承的方式，增加对象的功能。 但是是这样的么？ 留爪爪，以待思考。 (更多)

  装饰者模式：动态地将责任附加到对象上，想要扩展功能，装饰者提供有别于继承的另一种选择

  设计原则：

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

  这个模式不是很理解，感觉就是通过继承的方式，增加对象的功能。

  但是是这样的么？

  留爪爪，以待思考。 (收起)

  2011-12-29 14:43:17   回应

  收藏

  推荐