“对象性能”模式
面向对象很好地解决了“抽象”的问题，但是不可避免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略，但某些情况，面向对象所带来的成本必须谨慎处理。
典型模式
- Singleton
- Flyweight
Singleton 单件模式
动机
- 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们逻辑正确性和良好的效率。
- 如何绕过常规的构造器，提供一种机制来保证一个类只有一个示例。
- 这应该是类设计者的责任，而不是使用者的责任。
模式定义
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
结构
Singleton
要点总结
- Singleton模式中的实例构造器可以设置为protected以允许子类派生。
- Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。
- 注意多线程环境下实现安全的Singleton，注意对双检查锁的正确实现。
Flyweight 享元模式
动机
- 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。
- 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？
模式定义
运用共享技术有效地支持大量细粒度的对象。
结构
Flyweight
要点总结
- 面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
- Flyweight采用对象共享分做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。具体实现方面，要注意对象状态的处理。
- 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。
“状态变化”模式
在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案。
典型模式
- State
- Memento
State 状态模式
动机
- 在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
- 如何在运行时根据对象的状态来透明地更改对象行为？而不会为对象操作和状态转化之间引入紧耦合？
模式定义
允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。
结构
State
要点总结
- State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
- 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
- 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。
