抽象角色：声明真实对象和代理

Bridge模式在实际系统中经常应用的模式。它最能体现设计模式的原则针对接口进行编程，和使用聚合不使用继承这两个原则。

　　由于我们过分的使用继承，使类的结构过于复杂，不易理解，难以维护。特别是在Java中由于不能同时继承多个类，这样就会造成多层继承，维护更难。

　　Bridge模式是解决多层继承的根本原

设计可升级的架构，关键是要把不变的部分和预测可变的部分分开，以防止升级过程中对基本代码的干扰，业务流程不变，业务单元可能改变，这种分离可以有多种方式，可以从横向，纵向以及外围三个方面考虑。

1.模板方法（Template Method）

软件复用的关键是寻找相似性，很多情况下相似性表现为业务流程相似但业务单元具有特殊性。如果是这样可以定义一个业务流程骨架，而将一些业务单元的实现延伸到子类中去，

应用程序上下文接口：ApplicationContest.java

package com.longtop.zhmh;

public interface ApplicationContext {
    public Object getBean(String id) throws Exception;
}

上下文实现类：FileSystemXmlApplicationContext.java

package com.longtop.zhmh;

import java.lang.reflect.M

帕累托最优是以提出这个概念的意大利经济学家维弗雷多·帕雷托的名字命名的， 维弗雷多·帕雷托在他关于经济效率和收入分配的研究中使用了这个概念。

　　帕累托最优（Pareto Optimality），也称为帕累托效率（Pareto efficiency）。帕累托最优和帕累托改进，是博弈论中的重要概念，并且在经济学、工程学和社会科学中有着广泛的应用。

　　帕累托最优是指资源分配的一种状态，在不使任何人境况变坏的情况下，不可能再使某些人的处境变好。

　　帕累托改进（Pareto improvement），是指一种变化，在没有使任

一个学经济的朋友指出，我在这件事上连续犯了两次同样的错误——买衣服只因为逛了很久的街，穿衣服只因为花过了钞票。这种“傻事”在行为决策学上叫作“沉没成本谬误”。意思是说：人们在判断是否要做一件事情的时候，实际上只应该考虑两个因素：“它将给你带来多少好处”和“你需要为它付出多大成本”。但是，很多人还是习惯于把之前已经为这件事做过的投入也考虑进来——虽然这些投入不管是对是错，都是不可能再收回的了。

　　实际上，我逛了一个下午