设计模式读书笔记

1，找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2，针对接口编程，而不是针对实现编程；
3，多用组合（Composition），少用继承(inherit)
4，策略模式（StrategyPattern）:定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
5，良好的OO设计必须具备可复用，可扩充，可维护三个特征；
6，观察者模式（ObserverPattern）：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知，并执行各自定义的操作。
7，为了交互对象之间的松耦合设计而努力。
8，类应该对扩展开放，对修改关闭。
9，装饰者模式（DecoratePattern）:动态的将责任附加到对象上。若要扩展功能，装饰者提供了比集成更有弹性的替代方案。
9.1，装饰者和被装饰者对象有相同的超类型；
9.2，你可以用一个或多个装饰者包装一个对象；
9.3，既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象（被包装的）的场合，可以用装饰过的对象替代它。
9.4，装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的。
9.5，对象可以在任何时候被装饰，所以可以在运行时动态的、不限量的用你喜欢的装饰者来装饰对象。
9.6，装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。

9.7，装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂。

10,工厂方法模式（Factory MethodPattern）：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
11,依赖倒置原则（Dependency InversionPrinciple）：要依赖抽象，不要依赖具体类。此原则说明：不能让高层组件（是由其它低层组件定义其行为的类）依赖低层组件，而且，不管高层还是低层组件，“两者”都应该依赖于抽象。
12.1，变量不可以持有具体类的引用：如果使用New，就会持有具体类的引用。你可以改用工厂来避免这样的做法。
12.2，不要让类派生自具体类：如果派生自具体类，你就会依赖具体类，请派生自一个抽象（抽象类或者接口）。
12.3，不要覆盖基类中已经实现的方法：如果覆盖基类已实现的方法，那么你的基类就不是一个真正适合被继承的抽象。基类中已实现的方法，应该由所有的子类共享。
13，抽象工厂模式（Abstract FactoryPattern）：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
13.1，抽象工厂允许客户使用抽象的接口来创建一组相关的产品，而不需要知道实际产出的具体产品是什么。这样一来，客户就从具体的产品中被解耦。
14，工厂方法和抽象工厂，都可用于复杂将客户从具体类型中解耦：
14.1，抽象工厂和工厂方法都负责创建对象，但是工厂方法使用继承（把对象的创建委托给子类，子类实现工厂方法来创建对象），而抽象工厂通过对象的组合（对象的创建被实现在工厂接口所暴露出来的方法中）。
14.2，利用工厂方法创建对象，需要扩展一个类，并覆盖它的工厂方法。
14.3，抽象工厂提供一个用来创建一个产品家族的抽象类型，这个类型的子类定义了产品被产生的方法。要使用这个工厂，首先需要实例化它，然后将它传入一些针对抽象类型所写的代码中。
14.4，抽象工厂的具体工厂经常实现工厂方法来创建各自的产品，而对于工厂方法，抽象创建者中实现的代码通常会用到子类所创建的具体类型。
14.5，需要创建产品家族和想让制造的相关产品集合起来时，可以用抽象工厂。
14.6，如果目前还不知道将来需要实例化那些具体类时，可以用工厂方法。
14.7，所有的工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合。
14.8，工厂方法允许类将实例化延迟到子类进行。
14.9，抽象工厂创建相关的对象家族，而不需要依赖他们的具体实现。

15，单件模式（SingletonPattern）：确保一个类只有一个实例，并提供一个全局访问点。
16，命令模式（CommandPattern）：将“请求”封装成对象，以便使用不用的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
16.1，命令模式将发出请求的对象和执行请求的对象解耦；
16.2，在被解耦的两者之间是通过命令对象进行沟通的。命令对象封装了接收者和一个或一组动作；
16.3，调用者通过调用命令对象的execute()发出请求，这会使得接受者的动作被调用；
16.4，调用者可以接受命令当作参数，甚至可以在运行时动态的进行；
16.5，命令可以支持撤销，做法是实现一个Undo()方法来回到execute()被执行前的状态；
16.6，宏命令是命令的一种简单的延伸，允许调用多个命令。宏方法也可以支持撤销；
16.7，实际操作时，很常见使用“聪明”命令对象，也就是直接实现了请求，而不是将工作委托给接收者；
16.8，命令也可以用来实现日志和事务系统。
17，适配器模式（AdapterPattern）：将一个类的接口，转换为客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
18，对象适配器和类适配器使用两种不同的适配方法：分别是组合和继承。
19，外观模式（FacadePattern）：提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
20，外观和适配器可以包装许多类，但是外观的意图是简化接口，而适配器的意图是将接口转化为不同的接口。
21，外观没有封装子系统的类，外观只提供简化的接口。所以如果客户觉得有必要，依然可以直接使用子系统的类。这是外观模式一个很好的特征：提供简化的接口的同时，依然

将系统完整的功能暴露出来，以供需要的人使用。
22，最少知识原则（Least Knowledge Principle）：也称之为Law ofDemeter,减少对象之间的交互，只和“密友”谈话。这就是说，当你正在设计一个系统，不管是任何对象，你

都要注意它所交互的类有哪些，并注意它和这些类是如何交互的。这个原则希望我们在设计中，不要让太多类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果许

多类之间相互依赖，哪么这个系统就会变成一个易碎的系统，他需要花费许多成本维护，也会因为太复杂而不容易被其他人了解。
23，在一个对象内部，我们只应该调用属于以下范围的方法：（1）该对象本身；（2）被当作方法的参数而传递进来的对象；（3）此方法所创建或者实例化的任何对象；（4）对

象的任何组件（被实例变量所引用的任何对象，HAS-A关系）。
24，如果某对象是调用其他的方法的返回结果，不要调用该对象的方法。例如; A a = B.foo(); returna.foo2(); 不符合这一原则。
25.1，当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器。
25.2，当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。
25.3，适配器改变接口以符合客户的期望；
25.4，外观将客户从一个复杂的子系统中解耦；
25.5，实现一个外观，需要将子系统组合进外观之中，然后将工作委托给子系统执行；
25.6，适配器模式有两种形式：对象适配器和类适配器，类适配器需要用到多重继承；
25.7，可以为一个子系统实现一个以上的外观；
25.8，适配器讲一个对象包装起来以改变其接口；装饰者模式将一个对象包装起来以增加新的行为和责任；而外观将一群对象“包装”起来以简化其接口。