意图
将抽象部分与它的实现部分分离,使它们都可以独立地变化。(GoF)
场景
现在我们有很多表要处理,同时又有很多操作要做。最简单的做法是在一个类里做完所有的操作,如我们在EJB服务器端的实现中进行JDBC操作。可是这样一来这个类将无比巨大,大到四只眼(眼睛兄)都看不过来!
有什么好办法能够降低这样操作的杂乱性呢?我们注意到这里有两个概念,分别是“表单(Table)”和“操作(Operator)”。也就是说这里有两个部分——“抽象”和“实现”。我们将这两个部分进行分离,然后根据需要,分别继承和实现表单和操作。这样我们就可以方便地通过表单和操作的组合来实现我们的工作了。
操作如:
- Tabletbl1=newTable1(newInsert());
- tbl1.work();
- Tabletbl2=newTable2(newUpdate());
- tbl2.work();
Table1和Table2都是Table的子类,他们都映射到数据库中特定的表。Insert和Update都是接口Operator的实现,分别完成特定的数据库操作。
好了,下面来先看看Operator的实现代码。
- publicinterfaceOperator{
- /**
- *操作
- *
- *@paramarg传入的参数
- *@return操作结果
- */
- Stringwork(Stringarg);
- }
我们需要能对数据库进行插入和修改操作,因此分别建立Insert和Update类。
- //插入操作
- publicclassInsertimplementsOperator{
- publicStringwork(Stringarg){
- Stringrs="insert"+arg;
- returnrs;
- }
- }
- //修改操作
- publicclassUpdateimplementsOperator{
- publicStringwork(Stringarg){
- Stringrs="update"+arg;
- returnrs;
- }
- }
好了,我们再来看看抽象部分的实现。这里我们的对象是Table。
- publicabstractclassTable{
- //内置一个操作接口
- protectedOperatorimpl=null;
- publicTable(Operatorimpl){
- this.impl=impl;
- }
- /**
- *由子类来具体实现此操作
- */
- publicabstractvoidwork();
- }
现在我们有两个表单需要进行操作,他们分别是Table1和Table2。
- publicclassTable1extendsTable{
- publicTable1(Operatorimpl){
- super(impl);
- }
- publicvoidwork(){
- System.out.println(this.impl.work("Table1"));
- }
- }
- publicclassTable2extendsTable{
- publicTable2(Operatorimpl){
- super(impl);
- }
- publicvoidwork(){
- System.out.println(this.impl.work("Table2"));
- }
- }
这样我们在进行数据库的操作的时候,便可以随意地根据实际情况进行表单与操作的组合,将表单与操作桥接在一起来完成我们的任务。
- //对table1进行插入操作
- Tabletbl1=newTable1(newInsert());
- tbl1.work();
- //对table2进行修改操作
- Tabletbl2=newTable2(newUpdate());
- tbl2.work();
小结
Bridge设计模式感觉上是通过将对象与操作进行分离,然后对这两个基本概念进行继承及实现,通过对对象及操作的各种组合来完成相应的工作。
P.S.一直想不到一个好的例子来说明Bridge模式,今天吃早饭的时候突然想到可以用来应用于数据库操作。这几天就先按照这种想法做一个demo看看效果如何。呵呵,不知道会不会又是一种重复造轮子的行为呢?不过作为一种实践体会我觉得也很值得。
本文介绍了一种利用桥接(Bridge)设计模式简化复杂数据库操作的方法。通过将表单(Table)与操作(Operator)分离,实现了两者的独立变化,从而降低了单一类处理多种数据库操作时的复杂度。
7154

被折叠的 条评论
为什么被折叠?



