23种设计模式（Bright模式）

1、问题场景

场景： 软件设计中最头疼的就是需求变化。不是有句话：杀一个程序员不需要动刀，改几次需求即可。面对这样那样的变动，仅靠不停地修改代码，并开始新一轮的测试。

问题： 怎样设计出由于需求变更而带来的代码推翻重来的问题呢。

2、解决办法

桥梁模式：将抽象部分与它的实现部分进行分离，使他们可以独立的变化。这里的抽象和实例不是我们通常都认为的父--子继承关系。接口与实现的关系，而是一种组合。换句话说就是抽象部分是被实现部分调用的，用以完成抽象部分的。（系统开发设计之初，分析变化的种类，将不变的框架抽象出来，然后再将变化的内容荣使用具体的子类来实现）。

使用环境：

1、系统中有多处用到类似的行为，或多个类似实例的组合；

2、系统中某个类的行为可能有不同种变化趋势。

UML图：

优缺点：将可变化部分单独封装起来，使得变化影响的范围缩小，减少不必要的编译代码；同时抽象部分和实现部分的变动不会影响利用桥梁模式搭建的系统框架。

---------------------------------------------------------------------------

Name：一个奔跑中的loser

E-mail：chenfeiyoucan@163.com

_________________________________________