技术文章 > 无废话C#设计模式之十二:BRIDGE

无废话C#设计模式之十二:BRIDGE

2018-02-25 13:19

文档管理软件,文档管理系统,知识管理系统,档案管理系统的技术资料:

本系列文章将向大家介绍一下C#的设计模式,此为第十二篇文章,相信对大家会有所帮助的。废话不多说,继续来看。

意图

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

场景

还是说我们要做的网络游戏,多个场景需要扩充的问题我们已经采用了创建型模式来解决。现在的问题就是,不仅仅是游戏场景会不断扩充,而且游戏的模式也在不断扩充。比如,除了最基本的战斗模式之外,还会有道具模式,金币模式等。

对于这种在多个维度上都会有变化或扩充需求的项目来说,可以考虑引入桥接模式。或许你会说,不管是什么场景,不管什么模式,都可以是抽象场景的一个子类,但是,如果这样的话,4个场景和3种模式就会产生12个子类,而10个场景5种模式就会有50个子类。一味进行继承并不是什么好方法,桥接模式的思想是把继承转化为组合,把乘法(10*5=50)转化为加法(10+5=15)。

示例代码
[code]
csharp
using System;
using System.Collections.Generic;
using System.Text;
namespace BridgeExample
{
class Program
{
static void Main(string[] args)
{
PatrixScene halfPaper = new HalfPaper();
halfPaper.Mode = new GoldMode();
halfPaper.LoadScene();
PatrixScene matrix = new Matrix();
matrix.Mode = new PrpoertyMode();
matrix.LoadScene();
}
}
abstract class PatrixScene
{
protected GameMode mode;
public GameMode Mode
{
get { return mode; }
set { mode = value; }
}
public abstract void LoadScene();
}
class HalfPaper : PatrixScene
{
public override void LoadScene()
{
Console.WriteLine(“Load HalfPaper Completed“);
mode.InitScene();
}
}
class Matrix : PatrixScene
{
public override void LoadScene()
{
Console.WriteLine(“Load Matrix Completed“);
mode.InitScene();
}
}
abstract class GameMode
{
public abstract void InitScene();
}
class PrpoertyMode : GameMode
{
public override void InitScene()
{
Console.WriteLine(“Init Property Mode Completed“);
}
}
class GoldMode : GameMode
{
public override void InitScene()
{
Console.WriteLine(“Init Gold Mode Completed“);
}
}
}
[/code]

代码说明

PatrixScene类是抽象化角色。虽然说针对第一维度也就是游戏场景,PatrixScene也是一个抽象,但是我觉得这里说的抽象化和实现化还是针对第二维度的,也就是游戏模式。

GameMode类就是实现化角色。你或许会说对于多个维度,把哪个作为抽象化角色呢?虽然维度是一个平行的概念,但是对于Bridge模式来说,我觉得它是把相对高层的角色作为抽象化角色,而把比较底层的操作作为实现化角色的。比如,对于场景和模式来说,模式是为场景服务的,我们就把场景作为抽象化角色。

HalfPaper和Matrix都是修正抽象化角色。按照GOF的定义是说修正父类的抽象化定义。其实,我觉得抽象化角色不一定必须是对方法有默认实现,并且由子类进行修正。

PropertyMode和GoldMode是具体实现化角色。它们用来实现实现化角色定义的接口。

从一个角度来说,抽象化和修正抽象化角色相对应实现化和具体实现化角色,从另外一个角度来说,抽象化和实现化角色对应修正抽象化和具体实现化角色。

客户端代码中直接选择合适的具体实现化角色。看到这里,你可能觉得和策略模式很像。其实,策略模式针对面更小一点,一是针对算法替换,二是只针对一个维度的变化点,因此它也就只有一个抽象角色。

何时采用

从代码角度来说,如果类型的继承是处于2个目的(违背单一职责原则)的话可以使用Bridge模式避免过多的子类。

从应用角度来说, 如果应用会在多个维度上进行变化,客户端希望两个维度(场景、游戏模式)的对象相对独立,动态耦合(客户端决定哪个场景和哪个游戏模式耦合)的时候可以考虑Bridge模式。

实现要点

选择合适的类型作为抽象化角色(第一维度)。

抽象化角色和实现化角色通过组合进行关联。

抽象和实现不绑定,允许客户端作切换。