7/23 结构型设计模式：桥接模式

桥接模式是将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interfce)模式。

emmm… 上述描述是将百度百科的描述粘贴过来的，反正我觉得很绕的。我理解桥接模式是：

现在给我们提供了别人实现或者分装好的模块，而我们由于项目的问题或者技术能力深度问题导致我们没有办法进行修改，故采用再封装一层的解决方法。而这个的解决如下：

• 将ADO.Net中对于各类关系型数据库的访问封装为IDBHelper，提取共性(如果有不妨再提取AbstructDBHelper)，在封装每一种数据库的操作如：SqliteDBHelper、AccessDBHelper、OracleDBHelper、PostgresqlDBHelper、MySqlDBHelper、SqlServerDBHelper等。

• 由于数据操作多元化，不光是一个平台的操作，如博主专业地理信息中对于空间数据的操作，大部分人学习和使用都是ArcGIS，那么将其理解数据库就应该由ISpatialDBHelper，抽象类BaseSpatialDBHelper 但是现在 超图迎头赶上且开源访问也有苗头，那么我们是不是改覆写子类：总结子类如下：ArcGIS平台(SHPSpatialDBHelper、MDBSpatialDBHelper、GDBSpatialDBHelper、SqliteSpatialDBHelper、SDESpatialDBhelper)，Oracle平台（OracleSpatialDBhelper）、PostGIS平台(PostGISDBHelper),超图(SuperMapDBHelper),NTS开源访问(NTSDBBHelper)

  类图我就不绘制了。和上面一样。

• 有一些操作一样，但是使用的底层技术不一样，如以前博客中讲的Doc文档的操作，分为NPOI、Docx、Aspose.Words、甚至于Office，他们都是对于一个Word文档的操作，但是解决的问题角度与重点不一样。不可能说每一个人了解和使用Word操作就需要了解其中的细节，那么作为架构或者习惯良好的封装者是不是应该只抛出抽象模块，而不应该让别人频繁的了解细节。具体可以参考之前写的博客。

• 在软件构建过程中，随着需求和业务的发张，可能对于一个对象类的理解逐渐丰满、维度增加，这个时候就可以使用嫁接模式对其增加维度。

以上是我总结到的4处使用的，是我在使用嫁接模式的理解。