关于设计模式的一些记录

        设计模式是一种解决常见软件设计问题的经验总结和指导性工具，是经过大量实践证明有效的最佳实践。设计模式并不是具体的代码，而是一种解决问题的思想和理念，常见的设计模式有单例模式、工厂模式、观察者模式、模板模式、命令模式、访问者模式等。设计模式的应用可以提高代码的复用性、可读性、可维护性和可扩展性，同时也是提高软件设计能力和编程技能的重要途径。

Abstract Factory  抽象工厂模式

        应用 Abstract Factory 模式可以实现对象可配置的、动态的创建。灵活运用 Abstract Factory 模式可以提高软件产品的移植性，尤其是当软件产品运行于多个平台，或有不同的功能配置版本时，抽象工厂模式可以减轻移植和发布时的压力，提高软件的复用性。

 

Singleton 模式 单例模式

        在 Singleton 中， 通过将 Singleton 类的构造函数设为 protected 型（或 private）来防止外部对其直接初始化。需要访问 Singleton 的程序必须通过 getInstance()方法来获得一个 Singleton。在 getInstance() 中仅创建一次 uniqueInstance 就可以保证系统中的唯一实例。 对于 Singleton 中的 uniqueInstance 有两种不同的初始化策略（Lazy Initialization 和 Early Initialization 而且需要考虑线程安全问题）。

Decorator 模式

        

        Decorator 模式可以动态地扩展类的功能，同时又避免继承出大量的子类，比继承的方法更灵活。由于 Decorator 提供了动态的扩展方法，因此可以随时根据具体需求产生新的装饰类，从而可以在一定程度上避免层次较高类的复杂性。但是大量使用 Decorator 模式会造成系统中出现很多接口类似的小装饰对象，这样就造成系统可维护性的下降。

Facade/Session Facade 模式

        Facade 模式屏蔽了子系统的细节，降低了客户程序使用这些子系统的复杂度，同时也降低了客户程序和子系统的耦合程度。这样就从需要让所有的人了解所有的子系统接口变成让个别专家抽象子系统的接口。 Facade 模式应用起来非常灵活，也没有特定的实现，其应用的关键就是抽象出合理的Facade 接口。

Mediator 模式

        Mediator 封装了一组对象间的通信，降低了 Colleague 之间的耦合性，单个 Colleague

的变化不会影响到其他的对象。不过当 Colleague 比较多，且其中的关系复杂时，中介类 ConcreteMediator 会变得非常复杂，难以维护。

        Mediator 模式在 GUI 方面有较多的使用。当一个窗体或表单或对话框中有多个需要互

相通信的对象时——例如显示部门中人员的下拉列表需要根据部门下拉列表不同的选择而

变化，使用 Mediator 封装通信可以降低这些对象的耦合性，提高系统的可维护性。

Observer 模式

        在 Observer 模式中，实现了具体对象和观察者之间的抽象耦合。虽然 Subject 了解目 前有哪些观察者需要捕获自己状态的变化，但它并不了解这些观察者要做什么；而每一个观察者仅仅知道自己捕获到对象的变化，但并不清楚目前有多少观察者在观察对象的状态，也不需要通知其他的观察者。这样，动态的增加和移除观察者是非常简单的。通过 Observer 模式可以实现对象间的消息广播，这在很多处理中非常有用。不过广播的副作用是增加了系统的负载，任何消息都将被自动地发送到每一个观察者中，每一个观察者都将根据这些消息作出响应，这些响应未必都是必要的。在使用 Observer 模式时一定要注意精确地定义对象状态变化的依赖关系，以避免线程阻塞问题。

Intercepting Filter 模式

        使用 Intercepting Filter 模式使得预处理的逻辑和真正的处理逻辑分离，进行实际处理的 Target 只需要关心具体的逻辑，而同请求相关的预处理都放在 FilterManager 中进行。 同时解除了这两类处理的耦合性，扩展、修改预处理过程变得容易，系统具有更好的维护性和扩展性。

        学习设计模式最重要的是理解，而不是生搬硬套。每种设计模式中都包含着良好的设计 架构的思想，如隐藏内部细节、降低耦合度等，越是复杂的系统越需要这些思想的支撑。