面向对象很好地解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本须谨慎处理。
典型的模式有 ： Singleton 单件模式， Flyweight
单件模式
在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只有一个实例，才能保证它们的逻辑正确性，以及良好的效率。
单件模式保证一个类仅有一个实例看，并提供一个该实例的全局访问点。
Flyweight
在软件系统采用纯粹对象方案的问题在于大量细粒度的对象很快充斥在系统中，从而带来很高的运行时代价－主要是指内存需求方面的代价。
如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式进行操作。
Flyweight通过运用共享技术有效地支持大量细粒度的对象。
“状态变化” 模式
在组建构建过程中，某些对象的状态进程面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案
"数据结构"模式
常常有一些组建在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大的破坏组件的附庸。这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与特定数据无关的访问，是一种行之有效的解决方案。
Composite 、Iterator 、 Chain of Resposibility
Composite
软件在某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部的视线结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。
如何将 “客户代码于复杂的对象容器结构” 解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器。
composite 模式是将对象组合成树形结构以表示“部分－整体” 的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。
Iterator
在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种 “透明遍历” 也为 “同一种算法在多种集合对象上进行操作” 提供了可能。
使用面向对象技术将这种遍历机制抽象为 “迭代器对象” 为 “应对变化中的集合对象” 提供了一种优雅方式。
Iterator 模式 提供了一种方案顺序访问一个聚合对象中的各个元素，而又不仅暴露（稳定）该对象的内部表示。
Chain of Resposibility
在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行中只能有一个接受者，如果显示指定，将必不可少地带来请求发送者于接受者的紧耦合。
如何使请求发送者不需要指定具体的接受者？让请求的接受者自己在运行中来决定处理请求，从而使两者解耦。
Chain of Resposibility 的模式使多个对象都有机会处理请求，从而避免请求的发送者何接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
“行为变化” 模式
在组建的构建过程中，组件的行为变化经常导致组件本身的剧烈的变化。“行为变化” 模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。
典型的模式有 Command, Visitor
Command
在软件构建过程中，“行为请求者” 与 “行为实现者” 通常呈现一种 “紧耦合”。 但在某些场合－比如需要对行为进行 “记录、撤销／重做（undo/redo）、事务” 等处理，这种无法抵御变化的紧耦合是不适合的。
在这种情况下， 如何将 “行为请求者” 与 “行为实现者” 解耦？ 将一组行为抽象为对象，可以实现二者之间的松耦合。
Command 模式是将一个请求（行为）封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。
Visitor
在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为，如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。
如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？
Visitor 表示一个作用与某对象结构中各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用与这些元素的新操作（变化）。
