目录
一、设计模式入门与策略模式
1.使用模式最好的方式是：“把模式装进脑子里，然后在你的设计和已有的应用中，寻找何处可以使用它们。”
2.软件开发的一个不变真理：改变
3.第一个设计原则：分离需要变化的代码和不需要变化的代码，将前者独立封装，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的代码部分=>代码变化引起的不经意后果减少，系统变得更具有弹性
4. 3中提到的概念几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让“系统中的某部分改变不会影响其他部分”
5.第二个设计原则：针对接口编程，而不是针对实现编程。
5.1解释：这里我对“编程”的理解是广义设计程序与写代码的结合；“针对A编程”的理解：以A做背景（前提）的编程；“针对接口编程”的理解：在使用超类型(supertype)的结构下设计程序
5.2我们利用接口(interface、行为类)代表每个行为，而行为的每个实现(interface的子类、实现类)都将实现其中的一个接口
5.3两者区别举例：前者：针对同类不同对象根据不同子类区分功能；后者：在功能实现过程中识别不同对象（例如if-else）应该使用的功能
6.原则与模式可以应用在软件开发周期的任何阶段
7.将行为独立为一个类后，在原来的具体类里该行为也应由一个方法变为对象+方法
8.在运行过程中想要改变行为时，只要调用行为对应对象的setter方法即可达到改变行为的目的
9.第三个设计原则：多用组合，少用继承。“有一个”可能比“是一个”更好
10.使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以在运行时动态地改变行为，但是组合的行为对象要符合正确的接口标准（算法族：一组行为=>一族算法）
11.第一个设计模式：策略模式，定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户
12.使用模式和他人沟通时，可以使用更少的词汇做更充分的沟通，谈论软件系统时保持在设计层次，不要压低到对象与类这些琐碎的实现细节上面
13.模式不只是利用OO设计原则，隐含经验整理成了一群“设计模式”
14.要点摘抄：
14.1知道OO基础，并不足以让你设计出良好的OO系统
14.2模式不是被发明，而是被发现
14.3大多数的模式和原则，都着眼于软件变化的主题
14.4模式让开发人员之间有共享的语言，能够最大化沟通的价值
二、观察者模式
1.实例比喻：报纸出版者（主题Subject）+报纸订阅者（观察者Observer）=观察者模式
2.观察者与主题两种角色可以重叠，例如一个观察者作为主题，在得知它对应的主题信息更新后通知它对应的观察者信息
3.观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新
4.实现观察者模式的方法不只有一种，但是以包含Subject与Observer接口的类设计的做法最常见
5.设计原则：为了交互对象之间的松耦合设计而努力
5.1两个对象之间松耦合：依然可以交互，但是不太清除彼此的细节
5.2观察者模式提供了一种对象设计，让主题和观察者之间松耦合
5.3由于两者并非紧耦合，我们可以独立地复用主题或观察者
5.4改变主题或观察者其中一方，并不会影响另一方，只要它们之间的接口仍被遵守，我们就可以自由地改变它们
5.5松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的相互依赖降到了最低
5.6“耦合”的理解：耦合不是简单的调用，而是依据调用代码内容做更改后的调用。例如：直接调用a.aa()是松耦合；“若a是A，调用a.aa()，否则如何”这样是紧耦合。或者说不根据彼此代码而作适应性编程就是松耦合
6.Java内置的Observer模式不只支持主题推数据给观察者，还支持观察者从主题拉数据
6.1.java.util.Observable中的Obserable是一个类，违反针对接口编程的原则；类中setChanged()被保护，要更改函数必须继承，违反多用组合的原则
6.2若设计中可以扩展java.util.Observable，则Java自带的API可以符合需求，否则需要自己设计一整套观察者模式的代码
6.3在JDK中，并非只有在java.util中才能找到观察者模式，在JavaBeans和Swing中也存在观察者模式
7.要点摘抄：
7.1使用此模式时，你可从被观察者处推或拉数据，推的方式被认为更“正确”
7.2有多个观察者时，不可以依赖特定的通知次序
7.3要注意java.util.Observable实现上所带来的一些问题
三、装饰者模式
1.最重要的设计原则之一：类应该对扩展开放，对修改关闭
1.1开放的：扩展行为，添加行为代码
1.2关闭的：不允许修改现有的、正确的代码
1.3这样的设计具有弹性，可以应对改变，可以接受新的功能来应对改变的需求
2.不需要使设计的每个部分都遵循开放-关闭原则（每个地方都采用开放-关闭原则是一种浪费，遵循此原则通常需要引入新的抽象层次、增加代码复杂度），只需要将注意力集中在设计中最有可能改变的地方，然后应用开放-关闭原则
3.装饰者模式：动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的代替方案
3.1关键点：装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的
3.2装饰者和被装饰对象有相同的超类型
3.3既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象（被包装的）场合，可以用装饰过的对象代替它（迭代装饰）
4.装饰者继承抽象父类是为了有正确的类型，而不是继承它的行为。行为来自于装饰者和基础组件或与其他装饰者间的组合关系
5.通常装饰者模式是采用抽象类，但在Java中可以使用接口
6.装饰者通常是用其他类似于工厂或生成器这样的模式创建的，它们会被封装得很好，不会因其更多对象而犯错
7.Java中使用装饰者模式的例子：Java I/O(java.io)
8.装饰者模式的弊端：有时候会在设计中加入大量的小类，偶尔会导致别人不容易了解我的设计方式，干扰依赖特定类型的代码，增加代码复杂度
9.要点摘抄：
9.1组合和委托可用于在运行时动态地加上新的行为
9.2装饰者类反映出被装饰的组件类型
9.3可以用无数个装饰者包装一个组件
9.4装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型
四、工厂模式
1.代码绑着具体类会导致代码更脆弱，更缺乏弹性=>new时相当于针对实现编程，要优化实例化具体类的代码
2.简单工厂，不是一个设计模式，而是一种编程习惯，有人为人误认为是“工程模式”
2.1组成元素：客户(store)、工厂(factory)、产品
2.2客户选择产品类型，工厂创建产品，客户从工厂获取
3.利用静态方法定义一个简单的工厂，但有无法继承改变的缺点（静态方法无法被重写）
4.所有的工厂模式都用来封装对象的创建，工厂方法模式通过让子类决定该创建的对象是什么，来达到将该对象创建的过程封装的目的
5.工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类（与简单工厂相比，失去中间类：factory，由抽象工厂类选择产品种类，它的子类决定生产方式并生产）
5.1“子类决定”中“决定”并不是指模式允许子类本身在运行时做决定，而是指在编写创建者类时，不需要知道实际创建的产品是哪一个，选择了使用哪一种子类，自然就决定了实际创建的产品是什么
5.2抽象的工厂类提供了一个创建对象的方法的接口，也称为“工厂方法”
5.3在抽象的工厂类中，任何其他实现的方法，都可能使用到这个工厂方法所制造出来的产品，但只有子类真正实现这个工厂方法并创建产品
5.4工厂方法用来处理对象的创建，并将这样的行为封装在子类中=>客户程序中关于超类的代码与子类对象创建代码解耦
6.若只有一个具体创建者，工厂方法模式帮助我们将产品的实现从使用中解耦，由于创建者与产品不是紧耦合关系，增加或改变产品不会影响创建者
7.工厂方法和创建者并不一定是抽象的
8.设计原则：（依赖倒置原则）要依赖抽象，不要依赖具体类
8.1“依赖”含义：直接实例化一个对象就是依赖它的具体类，对于实例化的对象的具体实现的任何改变都会影响到主体（依赖前面对象的对象）
8.2此原则说明：不能让高层组件依赖底层组件，而且高底层都应依赖抽象（创建对象类应为抽象类）
8.3“高层”组件：由其他底层组件定义其行为的类
9.应用工厂方法后，高层组件与底层组件都依赖抽象（产品抽象类）
10.遵循依赖倒置原则的指导方针：
10.1变量不可以持有具体类的引用（不使用new，工厂模式中使用create，而真正的实例化过程分配到了声明变量的超类的子类，使变量不持有具体类的引用）
10.2不要让类派生自具体类（若派生自具体类就会依赖具体类）
10.3不要覆盖基类中已经实现的方法（若可以覆盖则基类不合格）
10.4上述方针不是不可违反，要根据自己的理解，如：可以随便实例化不可能改变的对象，对于可能改变的对象应用工厂
11.抽象工程模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类
11.1允许客户使用抽象的接口来创建一组相关的产品，而不需要知道实际产出的具体产品是什么
11.2客户从具体的产品中被解耦
11.3抽象工厂的方法经常以工厂方法的方式实现（超类声明抽象，子类覆盖实现）
12.工厂方法与抽象工厂：
12.1两者都用来（通过子类）创建对象，将创建封装，使应用程序解耦，降低其对特定实现的依赖
12.2工厂方法使用继承（继承一个工厂方法解决）
12.3抽象工厂使用组合（继承多个类似工厂方法组合产品解决）
12.4工厂方法将客户从具体类型中解耦，每次声明客户对象使用超类，实现用子类实现解耦
12.5抽象工厂声明客户同工厂方法，但是可以将相关产品结合作为最终产品
12.6抽象工厂用来创建整个产品家族，工厂方法用来创建单个产品
13.要点摘抄：
13.1所有的工厂都是用来封装对象的创建
13.2所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合
13.3工厂帮助我们针对抽象编程，而不是针对具体类编程
五、单件模式
1.单件常用来管理共享的资源，例如数据库连接或者线程池
2.单间模式：确保一个类只有一个实例，并提供一个全局访问点
2.1提供对实例的全局访问点，需要实例时，向类查询，它会返回单个实例
2.2可以应用延迟实例化的方式创建单件（类的基本组成：静态私有自身变量，私有构造方法，共有静态获取函数）（getInstance获取函数返回此变量，若为null还需要调用构造函数）
2.3“急切”实例化方式：直接在类的定义中声明唯一变量，getInstance不需要判断唯一变量是否实例化，直接输出唯一变量的结构
2.4改善多线程：<1>采用延迟实例化时，getInstance不关键可以直接用synchronized修饰此函数，但是需要程序接受getInstance造成的额外负担；<2>采用急切策略时，适用于应用程序总是创建并使用单件实例，或者在创建和运行时负担不繁重；<3>双重检查加锁，在getInstance中减少使用同步（判断实例未创建时使用同步synchronized），减少getInstance的时间耗费。
3.如果将类的所有组成都定义为静态，以类作为一个单件，可能导致混乱（与初始化次序相关的bug）
4.若使用单件模式的同时使用类加载器，需要自行指定加载器，并指定同一个类加载器
5.垃圾收集器不会吃掉单件
6.通常适合使用单件模式的机会不多
7.全局变量有可能因指向许多小对象来造成命名空间污染
8.要点摘抄：
8.1如果不是采用第五版的Java 2，双重检查加锁实现会失效
8.2如果使用JVM 1.2或之前的版本，必须建立单件注册表，以免垃圾收集器将单件回收
六、命令模式
1.命令模式：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作
1.1在ConcreteCommand中需要有具体接收者（行动者）的对象
1.2命令模式使请求调用者和请求接收者之间解耦
2.一个命令对象通过在特定接收者上绑定一组动作来封装一个请求
2.1命令对象将动作和接收者包进对象中，这个对象只留下一个公开的接口execute()
2.2“绑定”指通过单一职责使所有有关行为封装进指定接收者对象里，再将这些动作封装进公开的那个接口里
3.如果在返回对象时，不想返回null，可以考虑空对象（方法空）
4.宏命令：创建命令组对象，将组内execute组合调用
5.实现多层次撤销：应用堆栈记录
6.命令模式的更多用途：队列请求（将命令对象添加进工作队列）、日志请求（序列化记录动作）
7.要点摘抄：
7.1命令模式将发出请求的对象和执行请求的对象解耦
7.2在被解耦的两者之间通过命令对象进行沟通，命令对象封装了接收者和一个或一组动作
7.3命令可以支持撤销，实现undo()
七、适配器与外观模式
1.适配器用来将一种接口转换成另一种接口，以符合客户的期望
2.适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间
2.1可以让客户从实现的接口解耦
2.2被适配者的任何子类都可以搭配者适配器使用
2.3对象适配器（利用组合的方式将请求传递给被适配者）
2.4类适配器（需要多重继承，Java不可用）
3.类适配器可以覆盖被适配器的行为，有效率；对象适配器有弹性
4.外观模式在提供简化的接口的同时，依然将系统完整的功能暴露出来，以供需要的人使用
5.外观模式允许你将客户实现从任何子系统中解耦
6.适配器模式与外观模式的区别不在于“包装”了几个类，而在于意图：前者要改变接口来适应，后者来提供子系统的简化接口
7.外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用
7.1外观模式允许我们让客户和子系统之间避免紧耦合
7.2意图是提供一个简单的接口，让一个子系统更易于使用
8.设计原则：（“最少知识”原则）只和你的密友谈话（其他称呼：墨忒耳法则）
8.1减少对象之间的交互
8.2不要让太多的类耦合在一起
9.“最少知识”原则使用方针：就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法：
9.1自己的方法
9.2被当做方法的参数而传递进来的对象
9.3此方法所创建或实例化的任何对象
9.4对象的任何组件
9.5例子：
10.要点摘抄：
10.1可以为一个子系统实现一个以上的外观
10.2适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；外观将一群对象“包装”起来以简化其接口
八、模板方法模式
1.模板方法定义了一个算法的步骤，并允许子类为一个或多个步骤提供实现
2.模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤
2.1模板就是一个方法，这个方法将算法定义成一组步骤，其中的任何步骤都可以是抽象的，由子类负责实现
2.2确保了算法的结构保持不变，同时由子类提供部分实现
3.模板方法被声明为final，以免子类改变算法顺序
4.可以有“默认不做事的方法”，称这种方法为“hook”钩子，子类可以视情况要不要覆盖他们来实现选择的功能
5.钩子是一种被声明在抽象类中的方法，但只有空的或者默认的实现，它的存在可以让子类有能力对算法的不同点进行挂钩
6.当子类必须提供算法中某个方法或步骤的实现时，就使用抽象方法；如果算法的这个部分可选，用钩子。
7.钩子可以让子类实现算法中可选的部分，或者让子类能够有机会对模板方法中某些即将发生的步骤作出反应。
8.设计原则：（好莱坞原则）别调用（打电话给）我们，我们会调用（打电话给）你
8.1好莱坞原则可以防止“依赖腐败”（依赖设计混乱）
8.2在好莱坞原则之下，我们允许低层组件将自己挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些低层组件
8.3并不是低层组件禁止调用高层组件中的方法，而是要避免让高层和低层组件之间有明显的环状依赖
9.要点摘抄：
9.1你将在真实世界代码中看到模板方法模式的许多变体，不要期待它们全都是一眼就可以被你认出的
9.2策略模式和模板方法模式都封装算法，前者用组合，后者用继承
9.3工厂方法是模板方法的一种特殊版本
九、迭代器与组合模式
1.迭代器模式依赖于一个名为迭代器(Iterator)的接口
2.集合(collection)指一群对象，也称聚合(aggregate)
3.在多线程程序中要小心使用迭代器
4.迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示
4.1添加createIterator()方法创建迭代器，自创或用java.util.Iterator（Java里有的类支持迭代器）来实现Iterator接口
4.2这个模式提供了一种方法，可以顺序访问一个聚集对象中的元素，而又不用知道内部是如何表示的
4.3如果你有一个统一的方法访问聚合中的每一个对象，你就可以编写多态的代码和这些聚合搭配使用
4.4迭代器模式把在元素之间游走的责任交给迭代器，而不是聚合对象，简化聚合对象
5. 我们上面实现的是外部的迭代器，客户通过调用next取得下一个元素；内部的迭代器自行在元素之间游走，但需要将操作传入迭代器，让迭代器控制遍历的过程
6.设计原则：（单一责任）一个类应该只有一个引起变化的原因
7.内聚，用来度量一个类或模板紧密地达到单一目的或责任的术语
7.1当一个模块或一个类被设计成只支持一组相关的功能时，说明它具有高内聚
7.2当被设计成支持一组不相关的功能时，说明它具有低内聚
8.Java 5包含for/in语句，语法：for(Object obj: collection){}这可以让你在一个集合或者一个数组中遍历，而且不需要显式创建迭代器
9.组合模式：允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合
9.1组合对象可能包含其他组合对象和个别对象，个别对象只是个别对象
9.2使用组合模式，大多情况下，我们可以忽略对象组合和个别对象之间的差别
10. 所有组件都必须实现Component接口，但由于角色不同，有些方法不适用时最好抛出异常
11.组合迭代器(CompositeIterator)的工作是遍历组件内所有的个别对象，用到堆栈与递归
12.空迭代器(NullIterator)的hasNext()永远返回false，用来取代返回null的情况避免判断是否为null
13.要点摘抄：
13.1迭代器将遍历聚合的工作封装进一个对象中
13.2组合模式允许客户对个别对象以及组合对象一视同仁
13.3组合结构内的任何对象称为组件，组件可以是组合，也可以是叶节点
13.4在实现组合模式时，有许多设计上的折衷。要根据需要平衡透明性（用户可分辨对象种类）和安全性（对错的对象做错的事情、无意义的操作）
十、状态模式
1.状态模式通过改变对象内部的状态来帮助对象控制自己的行为
2.状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类
2.1状态模式将状态封装成为独立的类，并将动作委托到代表当前状态的对象
2.2使用组合通过简单引用不同的状态对象来造成类改变的假象
3. 策略模式与状态模式区别：（意图）状态模式中客户对Context改变了解不多甚至浑然不觉，而且支持组合不同的对象来改变行为；策略模式中客户通常指定Context所要组合的策略对象
4.一般来讲，当状态转换是固定的时候，就适合放在Context中；当转换是更动态的时候，通常就会放在状态类中。后者缺点是状态类之间产生依赖
5.在状态模式中客户不会与状态直接交互
6.要点摘抄：
6.1和程序状态机(PSM)不同，状态模式用类代表状态
6.2Context会将行为委托给当前状态对象
6.3状态类可以被多个Context实例共享
十一、代理模式
1.代理要做的：控制和管理访问
2.在开始编码之前，要先收集需求
3.远程对象：活在不同的Java虚拟机(JVM)堆中
4.本地代表：一种可以由本地方法调用的对象，其行为会转发到远程对象中
5.客户对象所做的就像是在做远程方法调用，但其实只是调用本地堆中的“代理”对象上的方法，再由代理处理所有网络通信的底层细节
6.Java RMI提供了客户辅助对象和服务辅助对象，为客户辅助对象创建和服务对象相同的方法
6.1RMI称呼：RMI将客户辅助对象称为stub（桩），服务辅助对象称为skeleton（骨架）
6.2客户堆：客户对象+客户辅助对象；服务器堆：服务对象+服务辅助对象
7.制作远程服务步骤：
7.1制作远程接口
7.2制作远程的实现
7.3利用rmic产生的stub和skeleton（运行rmic工具时，自动处理）
7.4启动RMI registry
7.5开始远程服务
8. 客户取得stub对象
9.对于RMI，程序员最常犯的三个错误：
9.1忘记在启动远程服务之前先启动rmiregistry
9.2忘记让变量和返回值的类型成为可序列化的类型
9.3忘记给客户提供stub类
10.使平常类变成服务（可接受远程调用）
10.1提供远程接口，该口提供了一组可以远程调用的方法
10.2确定接口的所有返回类型都是可序列化的
10.3在一个具体类中，实现此接口
11.代理模式：为另一个对象提供一个替身或占位符以控制对这个对象的访问
11.1使用代理模式创建代表对象，让代表对象控制某对象的访问，被代理的对象可以是远程的对象、创建开销大的对象或需要安全控制的对象
11.2代理控制访问的方式：远程代理控制访问远程对象；虚拟代理控制访问创建开销大的资源；保护代理基于权限控制对资源的访问
12.远程代理与虚拟代理：
12.1远程代理可以作为另一个JVM上对象的本地代表，利用网络交互
12.2虚拟代理（创造开销大的对象的代表）扮演对象的替身，将请求直接委托给对象
13.虚拟代理用法：显示CD封面，等待加载时间，虚拟代理可以代理Icon管理背景加载，加载未完成显示加载文字，加载完成显示委托给图片
14.可以向用户提供一个工厂来让客户使用代理
15.动态代理：实际的代理类在运行时创建的Java技术
16.使用Java API的java.lang.reflect包实现保护代理（一种根据访问权限决定客户可否访问对象的代理）的类图：
17.其他代理：
17.1防火墙代理：控制网络资源的访问，保护主题免于“坏客户”的侵害
17.2智能引用代理：当主题被引用时，进行额外的动作
17.3缓存代理：为开销大的运算结果提供暂时存储；允许多个客户共享结果，以减少计算或网络延迟
17.4同步代理：在多线程的形况下为主题提供安全的访问
17.5复杂隐藏代理：用来隐藏一个类的复杂集合的复杂度，并进行访问控制。也称外观控制
17.6写入时复制代理：控制对象的复制，方法是延迟对象的复制，知道客户真的需要为止
18.要点摘抄：
18.1远程代理管理客户和远程对象之间的交互
18.2虚拟代理控制访问实例化开销大的对象
18.3保护代理基于调用者控制对对象方法的访问
18.4Java内置的代理支持，可以根据需要建立动态代理，并将所有调用分配到所选的处理器
十二、复合模式
1.模式通常被一起使用，并被组合在同一个设计解决方案中
2.复合模式在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题
3.MVC（模型-视图-控制器）组成：
3.1控制器：取得用户的输入并解读其对模型的意思
3.2视图：用来呈现模型，通常直接从模型中取得它需要显示的状态与数据
3.3模型：持有所有的数据、状态和程序逻辑
3.4观察者模式：模型被视图与控制器观察
3.5策略模式：视图委托控制器来处理用户动作
3.6组合模式：视图的完成
4.控制器可以变成模型的观察者
5.控制器把控制逻辑从视图中分离，让模型和视图之间解耦
6.Model 2：MVC与Web的适配，使MVC符合浏览器/服务器模型（Servlet+JSP=>MVC的分离效果）
7.控制器不会实现应用逻辑，应用逻辑在模型中实现
8.要点摘抄：
8.1控制器是视图的策略，视图可以使用不同的控制器实现，得到不同的行为
8.2在Model 2中，控制器实现成Servlet，而JSP/HTML实现视图
十三、与设计模式相处
1.模式：在某情景下，针对某问题的某种解决方案
2.模式类目描述某个模式的意图、动机、可能应用该模式的地方、解决方案的设计以及使用后果
3.模式的描述：
4.三次规则：只有在真实的世界中被应用三次以上，才能算是一个模式
5.常见模式分类方法：
5.1根据模式的目标分成三个不同类目：创建型、行为型和结构型
5.2模式所处理的是类或是对象
6.快速开始用模式思考的指南：
6.1保持简单，不要为了用模式而用
6.2设计模式不是每次都完美无缺的
6.3要知道什么时候需要模式
6.4重构的时间就是模式的时间
6.5拿掉不需要的，不要害怕将一个设计模式从你的设计中删除
6.6如果现在不需要就不要做
7.反模式：告诉你如何采用一个不好的解决方案解决一个问题
十四、其他模式
博客其他版本：个人博客转载处
4972
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
