转载

设计模式系列12--桥接模式

设计模式系列12--桥接模式

假设要实现一个给客户发送提示消息的功能,发送的消息类型可分为:普通消息、加急消息、特加急消息等等,而每种消息的发送的方式一般有:系统内推送、手机短信、电子邮件等等。如果让我们来实现,会怎么做呢?

我们先来实现一个简单的版本,使用系统推送和电子邮件发送普通消息,实现起来不叫简单,就不展示代码了,直接看UML结构图

设计模式系列12--桥接模式

很简单的实现对吧,现在再增加一个加急消息的发送,也是通过系统推送和Email两种方式发送,而且加急消息还额外多了一个方法,想了想简单嘛,直接扩展现有的接口不就可以了吗,此时UML结构如如下:

设计模式系列12--桥接模式

如果在增加一个特加急消息的发送呢,也是两种方式,也有一个额外的方法,继续扩展嘛,此时UML机构如如下:

设计模式系列12--桥接模式

是不是感觉类的数目剧增了,还没完呢。现在需要给每种消息类型增加一种发送方式:手机发送。继续改,UML结构图如下:

设计模式系列12--桥接模式

此时类的数目已经非常多了,如果继续增加消息类型或者发送方式,那么又要重复扩展,类的数目会急剧增加。

我们来仔细分析下上面的实现,其实这里面有两个变化的维度:消息类型和发送方式。他们之间是交织在一起的,如下图所示:

设计模式系列12--桥接模式

由于这两个维度是交织在一起,那么他们之间的组合方式就有9种,也就是我们上面看到的有9个类,如果此时任何一个维度发生变化,都会导致与之关联的另一个维度也需要修改。而且一个维度的上的数目的增加,都会导致整体类的数目成倍数的增加。如果消息的发送类型和发送方式都有10种的话,那么就需要实现100个类,想想就恐怖。

那么自然而然的我们就想到把这两个维度分开,让他们独自变化,互不影响,需要用的是会把他们组合在一起就行了。这样一个维度的类增加,不会导致另一个维度类也需要跟着一起增加。

再次证明:多用组合少用继承

那么如何实现呢?这就要请出我们今天的主角:桥接模式。

定义

将抽象部分与它的实现部分分离,使它们都可以独立地变化。

抽象部分和实现部分就是两个不同的维度,抽象部分对应上面的消息类型,实现部分对应上面的消息发送方式。现在我们独立实现两个部分,然后消息类型部分想调用消息实现部分去发送消息该怎么办呢?很简单嘛,让抽象部分持有实现部分的接口,面向接口编程就可以了,这就是桥接模式名字的由来。桥接抽象部分和实现部分,下面看UML结构图会更加的清晰。

UML结构如及说明

设计模式系列12--桥接模式

可以看到抽象部分的抽象类和实现部分的接口是聚合关系,表示抽象部分持有实现部门的接口,这样抽象部分就可以调用实现部分完成功能了。

分析到这里,大家应该对桥接模式有一个大致的了解了吧,下面就来看看如何使用桥接模式来实现上面的消息发送功能。

代码实现

1、消息类型抽象类

#import <Foundation/Foundation.h>
#import "messageImplement.h"

@interface abstractMessage : NSObject
@property(strong,nonatomic)id<messageImplement> messageIm;

-(void)send:(NSMutableString*)message;
- (instancetype)initWithImplement:(id<messageImplement>)implement;
@end

====================
#import "abstractMessage.h"

@implementation abstractMessage

- (instancetype)initWithImplement:(id<messageImplement>)implement
{
    self = [super init];
    if (self) {
        self.messageIm = implement;
    }
    return self;
}

-(void)send:(NSMutableString*)message{

}

@end

2、具体消息类型

下面只展示了普通消息的具体类实现,其他两种方式类似,详细见demo

#import "abstractMessage.h"

@interface commonMessage : abstractMessage

@end


====================

#import "commonMessage.h"

@implementation commonMessage

-(void)send:(NSMutableString *)message{
    [message insertString:@"【普通消息:" atIndex:0];
    [message appendString:@"】"];
    [self.messageIm sendMessage:message];
}
@end

3、消息发送接口

#import <Foundation/Foundation.h>

@protocol messageImplement <NSObject>

-(void)sendMessage:(NSString *)message;

@end

4、具体的消息发送方式

下面只展示使用系统内推送方式发送消息的方式,其他两种消息发送方式类似,不在展示,具体见demo

#import <Foundation/Foundation.h>
#import "messageImplement.h"

@interface messageSMS : NSObject<messageImplement>

@end


=================

#import "messageSMS.h"

@implementation messageSMS

-(void)sendMessage:(NSString *)message{
    NSLog(@"使用系统内消息方式发送消息,消息内容:%@", message);
}
@end

5、测试

id<messageImplement> messageIMP = [messageMobile new];
 abstractMessage *message = [[specialUrgencyMessage alloc]initWithImplement:messageIMP];
 NSMutableString *mStr = [[NSMutableString alloc]initWithString:@"大海啊,全是水,骏马啊,四条腿"];
 [message send:mStr];

6、输出

2016-12-15 16:56:43.356 桥接模式[66573:2541266] 使用手机方式发送消息,消息内容:【特别加急消息:大海啊,全是水,骏马啊,四条腿】

你可以任意组合消息类型和消息发送方式,此时类的数目只有6个,比之前的继承实现方式9个少了。如果两者都有10种实现方式,那么使用继承方式就需要100个类,而使用桥接模式只要20个类,看到了桥接模式的巨大优点吧。

优缺点

设计模式系列12--桥接模式

思考

桥接模式,需要理解桥接二字的由来,看上面的UML图就明白了,是在抽象和实现之间桥接。因为他们现在分开了,但是抽象部分必须使用实现部分去实现功能,所以抽象部分必须引用实现部分,这就是桥接。

桥接模式对比继承的有点是把本来混在一起的两个变化未读分开,让他们独立变化,这样互相不影响,减少了类的数目,也方便扩展,而且可以动态替换功能。比如上面的消息发送功能,同样是发送普通消息,我可以选择手机、email其中的任何一种方式,只需要组合起来就行了,比继承更加灵活。

扩展下去,我们上面只是两个维度在变化,那么如果是三个、四个维度在变化呢?如果你使用继承去实现,那就完了,不知道要重复写多少代码,而使用桥接模式,就可以把这些变化维度全部独立分开实现,然后客户端想怎么组合就怎么组合。

Demo下载

桥接模式Demo

原文  http://blog.ximu.site/bridge-pattern/
正文到此结束
Loading...