Head First Design Partern[Note]

• 1.OO基础
• 2.OO原则
• 3.创建型模式
  • 3.1.抽象工厂 Abstract Factory
  • 3.2.生成器 Builder
  • 3.3.工厂方法 Factory Method
  • 3.4.原型 Prototype
  • 3.5.单件 Singleton
• 4.结构型模式
  • 4.1.适配器 Adapter
  • 4.2.桥接 Bridge
  • 4.3.组成(组合) Composite
  • 4.4.装饰(装饰者) Decorator
  • 4.5.外观 Facade
  • 4.6.享元 Flyweight
  • 4.7.代理 Proxy
• 5.行为模式
  • 5.1.职责链 Chain of Responsibility
  • 5.2.命令 Command
  • 5.3.解释器 Interpreter
  • 5.4.迭代器 Iterator
  • 5.5.中介者 Mediator
  • 5.6.备忘录 Memento
  • 5.7.观察者 Observer
  • 5.8.状态 State
  • 5.9.策略 Strategy
  • 5.10.模板方法 Template Method
  • 5.11.访问者 Visitor
• 6.要点
  • 6.1 设计模式入门
  • 6.2 观察者模式
  • 6.3 装饰者模式
  • 6.4 工厂模式
  • 6.5 单件模式
  • 6.6 命令模式
  • 6.7 适配器与外观模式
  • 6.8 模板方法模式
  • 6.9 迭代器与组合模式
  • 6.10 状态模式
  • 6.11 代理模式
  • 6.12 复合模式
  • 6.13 与设计模式相处
• 7.使用模式的心智

1.OO基础

1.1.抽象
1.2.封装
1.3.继承
1.4.多态

2.OO原则

2.1.找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2.2.针对接口编程，而不是针对实现编程。
2.3.多用组合，少用继承。
2.4.为了交互对象之间的松耦合设计而努力。
2.5.类应该对扩展开放，对修改关闭。
2.6.要依赖抽象，不要依赖具体类。
2.7.最少知识原则：只和你的密友谈话。
2.8.别调用（打电话给）我们，我们会调用（打电话给）你。
2.9.一个雷应该只有一个引起变化的原因。

3.创建型模式

3.1.抽象工厂 Abstract Factory

• 意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

• 结构：

• 案例：

3.2.生成器 Builder

• 意图：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
• 结构：

3.3.工厂方法 Factory Method

• 意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的 实例化延迟到其子类。

• 结构：

• 案例：

3.4.原型 Prototype

• 意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
• 结构：

3.5.单件 Singleton

• 意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

• 结构：

• 案例：

4.结构型模式

4.1.适配器 Adapter

• 意图：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容 而不能一起工作的那些类可以一起工作。

• 结构：

• 案例：

4.2.桥接 Bridge

• 意图：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
• 结构：

4.3.组成(组合) Composite

• 意图：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象 和组合对象的使用具有一致性。

• 结构：

• 案例：

4.4.装饰(装饰者) Decorator

• 意图：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

• 结构：

• 案例：

4.5.外观 Facade

• 意图：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

• 结构：

• 案例：

4.6.享元 Flyweight

• 意图：运用共享技术有效地支持大量细粒度的对象。
• 结构：

4.7.代理 Proxy

• 意图：为其他对象提供一种代理以控制对这个对象的访问。

• 结构：

• 案例：

5.行为模式

5.1.职责链 Chain of Responsibility

• 意图：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这 些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
• 结构：

5.2.命令 Command

• 意图：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。

• 结构：

• 案例：

5.3.解释器 Interpreter

• 意图：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示 来解释语言中的句子。
• 结构：

5.4.迭代器 Iterator

• 意图：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

• 结构：

• 案例：

5.5.中介者 Mediator

• 意图：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从 而使其耦合松散，而且可以独立地改变它们之间的交互。
• 结构：

5.6.备忘录 Memento

• 意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。 这样以后就可将该对象恢复到原先保存的状态。
• 结构：

5.7.观察者 Observer

• 意图：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象 都得到通知并被自动更新。

• 结构：

• 案例：

5.8.状态 State

• 意图：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

• 结构：

• 案例：

5.9.策略 Strategy

• 意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独 立于使用它的客户而变化。

• 结构：

• 案例：

5.10.模板方法 Template Method

• 意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类 可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

• 结构：

• 案例：

5.11.访问者 Visitor

• 意图：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提 下定义作用于这些元素的新操作。
• 结构：

6.要点

6.1 设计模式入门

• 知道OO基础，并不足以让你设计出良好的OO系统。
• 良好的OO设计必须具备可复用、可扩充、可维护三个特性。
• 模式可以让我们建造出具有良好OO设计质量的系统。
• 模式被认为是历经验证的OO设计经验。
• 模式不是代码，而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中。
• 模式不是被发明，而是被发现。
• 大多数的模式和原则，都着眼于软件变化的主题。
• 大多数的模式都允许系统局部改变独立于其他部分。
• 我们常把系统中会变化的部分抽出来封装。
• 模式让开发人员之间有共享的语言，能够最大化沟通的价值。

6.2 观察者模式

• 观察者模式定义了对象之间一对多的关系。
• 主题（也就是可观察者）用一个共同的接口来更新观察者
• 观察者和可观察者之间用松锅合方式结合（loosecoupling)观察者不知道观察者的细节，只知道观察者实现了观察者接口。
• 使用此模式时，你可从被观察者处推（push)或pull)数据（然而，推的方式被认为更 “正确”) 。
• 有多个观察者时，不可以依赖特定的通知次序。
• Java有多种观察者模式的实现，包括了通用的java.util.Observable。
• 要注意java.util.Observable实现上所带来的一些问题。
• 如果有必要的话，可以实现自己的Observable,这并不难，不要害怕。
• Swing大量使用观察者模式，许多GUI框架也是如此。
• 此模式也被应用在许多地方，例如：JavaBeans、RMI。

6.3 装饰者模式

• 继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式。
• 在我们的设计中，应该允许行为可以被扩展，而无须修改现有的代码。
• 组合和委托可用于在运行时动态地加上新的行为。
• 除了继承，装饰者模式也可以让我们扩展行为。
• 装饰者模式意味着一群装饰者类，这些类用来包装具体组件。
• 装饰者类反映出被装饰的组件类型（事实上，他们具有相同的类型，都经过接口或继承实现）。
• 装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的。
• 你可以用无数个装饰者包装一个组件。
• 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。
• 装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂。

6.4 工厂模式

• 所有的工厂都是用来封装对象的创建
• 简单工厂，虽然不是真正的设计模式，但仍不失为一个简单的方法，可以将客户程序从具体类解耦。
• 工厂方法使用继承：把对象的创建委托给子类，子类实现工厂方法来创建对象。
• 抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中。
• 所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合。
• 工厂方法允许类将实例化延迟到子类进行。
• 抽象工厂创建相关的对象家族，而不需要依赖它们的具体类。
• 依赖倒置原则，指导我们避免依赖具体类型，而要尽量依赖抽象。
• 工厂是很有威力的技巧，帮助我们针对抽象编程，而不要针对具体类编程。

6.5 单件模式

• 单件模式确保程序中一个类最多只有一个实例。
• 单件模式也提供访问这个实例的全局点。
• 在Java中实现单件模式需要私有的构造器、一个静态方法和一个静态变量。
• 确定在性能和资源上的限制，然后小心地选择适当的方案来实现单件，以解决多线程的问题（我们必须认定所有的程序都是多线程的）。
• 如果不是采用第五版的Java 2, 双重检查加锁实现会失效。
• 小心，你如果使用多个类加载器，可能导致单件失效而产生多个实例。
• 如果使用JVM 1.2或之前的版本，你必须建立单件注册表，以免垃圾收集器将单件回收。

6.6 命令模式

• 命令模式将发出请求的对和执行请求的对象解耦。
• 在被解耦的两者之间是通过命令对象进行沟通的。
• 命令对象封装了接收者和一个或一组动作。
• 调用者通过调用命令对象的execute()发出请求，这使得接收者的动作被调用。
• 调用者可以接受命令当做数，甚至在运行时动态地进行。
• 命令可以支持撤销，做法是实现一个undo()方法来回到execute()被执行前的状。
• 宏命令是命令的一种简单的延伸，允许调用多个命令 。宏方法也可以支持撤销。
• 实际操作时，很常见使用 “聪明”命令对象，也就是直接实现了请求，而不是将工作委托给接收者。
• 命令也可以用来实现日志和事务系统。

6.7 适配器与外观模式

• 当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器。
• 当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。
• 适配器改变接口以符合客户的期望。
• 外观将客户从一个复杂的子系统中解耦。
• 实现一个适配器可能需要一番功夫，也可能不费功夫，视目标接口的大小与复杂度而定。
• 实现一个外观，需要将子系统组合进外观中，然后将工作委托给子系统执行。
• 适配器模式有两种形式：对象适配器和类适配器。类适配器需要用到多重继承。
• 你可以为一个子系统实现一个以上的外观。
• 适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；而外观将一群对象“包装”起来以简化其接口。

6.8 模板方法模式

• “模板方法”定义了算法的步骤，把这些步骤的实现延迟到子类。
• 模板方法模式为我们提供了一种代码复用的重要技巧。
• 模板方法的抽象类可以定义具体方法、抽象方法和钩子。
• 抽象方法由子类实现。
• 钩子是一种方法，它在抽象类中不做事，或者只做默认的事情，子类可以选择要不要去覆盖它。
• 为了防止子类改变模板方法中的算法，可以将模板方法声明为final。
• 好莱坞原则告诉我们，将决策权放在高层模块中，以便决定如何以及何时调用低层模块。
• 你将在真实世界代码中看到模板方法模式的许多变体，不要期待它们全都是一眼就可以被你认出的。
• 策略模式和模板方法模式都封装算法，一个用组合，一个用继承。
• 工厂方法是模板方法的一种特殊版本。

6.9 迭代器与组合模式

• 迭代器允许访问聚合的元素，而不需要暴露它的内部结构。
• 迭代器将遍历聚合的工作封装进一个对象中。
• 当使用迭代器的时候，我们依赖聚合提供遍历。
• 迭代器提供了一个通用的接口，让我们遍历聚合的项，当我们编码使用聚合的项时，就可以使用多态机制。
• 我们应该努力让一个类只分配一个责任。
• 组合模式提供一个结构，可同时包容个别对象和组合对象。
• 组合模式允许客户对个别对象以及组合对象一视同仁。
• 组合结构内的任意对象称为组件，组件可以是组合 ，也可以是叶节点。在实现组合模式时，有许多设计上的折衷。你要根据需要平衡透明性和安全性 。

6.10 状态模式

• 状态模式允许一个对象基于内部状态而拥有不同的行为。
• 和程序状态机（PSM) 不同，状态模式用类代表状态。
• Context会将行为委托给当前状态对象。
• 通过将每个状态封装进一个类，我们把以后需要做的任何改变局部化了。
• 状态模式和策略模式有相同的类图，但是它们的意图不同。
• 策略模式通常会用行为或算法来配置Context类。
• 状态模式允许Context随着状态的改变而改变行为。
• 状态转换可以由State类或Context类控制。
• 使用状态模式通常会导致设计中类的数目大量增加。
• 状态类可以被多个Context实例共享。

6.11 代理模式

• 代理模式为另一个对象提供代表，以便控制客户对对象的访问，管理访问的方式有许多种。
• 远程代理管理客户和远程对象之间的交互。
• 虚拟代理控制访问实例化开销大的对象。
• 保护代理基于调用者控制对对象方法的访问。
• 代理模式有许多变体，例如：缓存代理、同步代理、防火墙代理和写入时复制代理。
• 代理在结构上类似装饰者，但是目的不同。
• 装饰者模式为对象加上行为，而代理则是控制访问。
• Java内置的代理支持，可以根据需要建立动态代理，并将所有调用分配到所选的处理器。
• 就和其他的包装者（wrapper) 一样，代理会造成你的设计中类的数目增加。

6.12 复合模式

• MVC是复合模式，结合了观察者模式、策略模式和组合模式。
• 模型使用观察者模式，以便观察者更新，同时保持两者之间解耦。
• 控制器是视图的策略，视图可以使用不同的控制器实现，得到不同的行为。
• 视图使用组合模式实现用户界面，用户界面通常组合了嵌套的组件，像面板、框架和按钮。
• 这些模式携手合作，把MVC模型的三层解耦，这样可以保持设计干净又有弹性。
• 适配器模式用来将新的模型适配成已有的视图和控制器。
• Model 2是MVC在Web上的应用。
• 在Model 2中 ，控制器实现成Servlet,而JSP/HTML实现视图。

6.13 与设计模式相处

• 让设计模式自然而然地出现在你的设计中，而不是为了使用而使用。
• 设计模式并非僵化的教条； 你可以依据自己的需要采用或调整。
• 总是使用满足需要的最简单解决方案，不管它用不用模式。
• 学习设计模式的类目，可以帮你自己熟悉这些模式以及它们之间的关系。
• 模式的分类（或类目）是将模式分成不同的族群，如果这么做对你有帮助，就采用吧！
• 你必须相当专注才能够成为一个模式的作家：这需要时间也需要耐心，同时还必须乐意做大量的精化工作。
• 请牢记：你所遇到大多数的模式都是现有模式的变体，而非新的模式。
• 模式能够为你带来的最大好处之一是：让你的团队拥有共享词汇。
• 任何社群都有自己的行话，模式社群也是如此。别让这些行话绊着，在读完这本书之后，你已经能够应用大部分的行话了。

7.使用模式的心智

• 初学者的心智：“我要为Hello World找个模式”。
• 初学者到处使用模式。这很好：初学者可以借此培养许多使用模式的实战经验。初学者也认为“我使用越多模式，我的设计就越好”。初学者将慢慢认识到并非如此，所有的设计都应该尽量保持简单。只有在需要实践扩展的地方，才值得使用复杂性和模式。
• 中级人员的心智：“或许这里我需要一个单件模式”。
• 随着学习的进程，中级人员的心智开始能够分辨何时需要模式，而何时不需要。中级人员的心智依然会企图把过多的模式套用在不适当的地方，但他们也开始察觉到有些模式并不适合目前的情况，可以对其改编使其适合。
• 悟道者的心智：在这里采用装饰者模式相当自然。
• 悟道者的心智能够看到模式在何处能够自然融入。悟道者的心智并不急切于使用模式，而是致力于最能解决问题的简单方案。悟道者的心智会考虑对象的原则，以及它们之间的折衷。当对模式的需要自然出现时，悟道者的心智就拿捏得宜地采用模式。悟道者的心智也能看到相似模式之间的关系，以及它们在意图上的微妙差异。悟道者的心智也同于初学者的心智—— 不会让这些模式的知识过度影响设计的决策。

1.弗里曼：Head First设计模式

2.Erich Gamma：Design Patterns(意图、结构图)

• ← Previous Post
• Next Post →