HeadFirst设计模式读后感

当涉及到维护时 为了复用而使用继承并不完美
设计原则

	封装变化
	针对接口编程 而不是针对实现编程
	多用组合 少用继承
	类应该对扩展开放 对修改封闭
	为交互对象之间的松耦合而努力
	要依赖抽象 不要依赖具体类	（变量不可持有具体类的引用，不要让类派生自具体类，不要覆盖类中乙实现的方法）
	最少知识原则（只和你的密友交谈）

策略设计模式

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

观察者模式

定义了对象一对多之间的依赖，这样以来，当一个对象改变状态时，他的所有依赖着都将会收到通知并自动更新

松耦合

当两个对象松耦合时，他们依然可以相互交互，但是不太清楚彼此间的细节

装饰着模式

利用继承得到类型匹配，而不是	利用继承获得行为
动态的将责任加到对象上。想要扩展功能，装饰着提供有别于继承的另一种选择。

工厂模式

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

抽象创造者类：定义了一个抽象的工厂方法让子类实现此方法制造产品，创造者通常包含依赖于抽象产品的代码而这些抽象产品由子类制造 创造者不需要真的知道在哪制造了那种具体产品
能生产产品的类称为具体创造者  另有抽象产品类 具体产品类

抽象工厂模式

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

提供一个抽象接口来创建一个产品家族 每个具体子类都创建一个家族的产品，这些负责在抽象工厂中创建产品的方法通常是以“工厂方法来实现”

单例模式

	确保类只有一个实例，并提供一个全局访问点

命令模式

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

适配器模式

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

外观模式

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

状态模式

允许对象在内部状态改变时改变她的行为 对象看起来好像修改了她的类

代理模式

为另外一给对象提供一个替身或者占位符以控制对这个对象的访问
		静态代理： 由程序员创建或工具生成代理类的源码，再编译代理类。所谓静态也就是在程序运行前就已经存在代理类的字节码文件，代理类和委托类的关系在运行前就确定了。 
						  业务类只需要关注业务逻辑本身 保证了业务类的重用 
					      代理对象的一个一个接口只服务于一种类型的对象 ，如果要代理的方法过多 则需要为每种方法提供实现 
					      如果接口发生了改动 则除了实现类需要修改 代理类也需要修改 增加了代码的维护复杂度

	    动态代理 动态代理类的源码是在程序运行期间由JVM根据反射等机制动态的生成，所以不存在代理类的字节码文件。代理类和委托类的关系是在程序运行时确定。 
	    	
	    				动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理（InvocationHandler.invoke）。这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。在本示例中看不出来，因为invoke方法体内嵌入了具体的外围业务（记录任务处理前后时间并计算时间差），实际中可以类似Spring AOP那样配置外围业务。 
	    				诚然，Proxy 已经设计得非常优美，但是还是有一点点小小的遗憾之处，那就是它始终无法摆脱仅支持 interface 代理的桎梏，因为它的设计注定了这个遗憾。回想一下那些动态生成的代理类的继承关系图，它们已经注定有一个共同的父类叫 Proxy。Java 的继承机制注定了这些动态代理类们无法实现对 class 的动态代理，原因是多继承在 Java 中本质上就行不通。