Head First设计模式学习笔记

前言

最近为了进一步加深对设计模式的理解，学习了《head first设计模式》。不同于之前的php设计模式的学习，java的设计模式更加灵活和“奇妙”。本文一方面对head first提出的设计模式、设计原则以及一些经典的代码架构观点进行了总结，同时也记录了自己对设计模式的一些理解，在此进行记录，以便于以后在实际的java框架理解和项目的开发过程中，进行灵活的应用。

1.  策略者模式

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

设计原则：

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
• 针对接口编程，而不是针对实现编程。
• 多用组合，少用继承。

该模式改良了java的继承机制在实际应用时的所出现的问题。

  该模式从全局定义了整个head first设计模式的学习基础，整个设计模式的学习需要建立新的思维模式，从过去面向实现编程，转变为面向接口编程，或者说是面向抽象进行编程。在抽象的层面（顶层设计），给出整个程序的架构，再一步一步的进入到底层具体的功能实现。

  具体的，在策略中模式中提出了针对不断变化的需求，如何在抽象层面，给出一个良好的代码架构，从而在以后的代码维护中节约成本。利用策略者模式，能更好的建立起可复用、易扩展、可维护的程序，其中最重要的两个设计原则则是：针对接口编程，而不是针对实现编程。多用组合，少用继承。将容易变化的部分，独立为模块，在抽象接口中定义好模块间的逻辑，最后不断的利用java的继承和多态特性，实现对维护和变化的需求。从而，对于已经完成测试的代码部分，不需要再进行更改，保证代码的复用，并节约了开发成本。

head first实例代码：http://download.csdn.net/download/u014454539/9946145

2.  观察者模式

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

  设计原则：

• 为了交互对象之间的松耦合设计而努力

该机制主要探讨了java类之间的耦合问题，当观察者(observer)与主题（subject）之间实现交互时，主题不需要了解观察者类的具体实现。其本质也是在抽象层面（abstract）完成观察者与主题类的映射，而多元化的主题类只需实现主题接口，则可以注册成为观察者，实现与主体的数据交互。

该模式很好的继承了策略者模式提出的设计原则，在基于接口的抽象层面进行相关逻辑的定义，利用多态和继承，在实现的具体类中完成具体的功能定义和实现。因此，观察者类与主体类只需实现对应接口，而不需要了解对方的具体实现。从而，达到在松耦合的设计下，实现多对一的映射关系并实现相关应用逻辑。

head first实例代码：http://download.csdn.net/download/u014454539/9946234

3.  装饰器模式

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

设计原则：

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

该模式进一步探讨java类直接使用继承来扩展类的功能的局限性。

当已经存在一个抽象类，无法重构代码使用接口机制时，常常采用装饰器模式对该类的功能进行扩展。每一次的封装，都可以在该类原有的功能基础上，进行扩展，保证了对扩展的开放性，对修改的关闭。

head first实例代码：http://download.csdn.net/download/u014454539/9946234

4.  工厂模式

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

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

设计原则：

• 要依赖抽象，不要依赖具体类。

工厂模式简单来说，既是将实例化对象的过程统一的放入一个类中进行实现，调用时只需传入相关参数，即可获得参数对应的实例化对象。当具体的实例化过程在多个业务类中被调用，同时当统一超类下的具体实例化类可能发生变化时，工厂模式能够给扩展和维护提供很好的便捷。

工厂方法模式，同样是基于面向接口编程的原则，在一个抽象类中，将实例化类的过程交给一个抽象方法，而所有超类的具体实现子类都需要实现该方法。从而当用户具体使用工厂模式时，只需要关注接口(API)，而不用关心具体的实现。

而在本设计模式下提出的设计原则中，则遵循不能让高层组件依赖底层组件，而且，无论高层或底层组件都依赖于抽象。

今天整理了4种设计模式，都是以策略者模式和对应相关的设计原则为核心进行推进的，设计模式的具体思路则都是以设计抽象和设计接口为顶层设计，在顶层设计中规定了具体的业务逻辑，将不同实现的差异性交给子类来完成。因此能保证用户在具体使用这些子类时，可以不用关注子类的具体使用，而之用关注接口。其余三种模式，则是在特定的需求下，进行一种抽象层面的归纳而形成的，可以在未来的具体应用场景中进行灵活的使用。