扩展系统功能
尽管目前房价依然在涨,但依旧阻止不了大家对新房的渴望和买房的热情。如果大家买的是毛坯房,还要面临一个艰巨的任务,那就是装修。对于新房进行装修,并没有改变房屋用于居住的本质,但是它可以让房子变得更漂亮、更温馨、更实用、更能满足居家需求。在软件设计中,也有一种类似新房装修的技术可以对已有对象(新房)的功能进行扩展(装修),以获得更加符合用户需求的对象,使得对象具有更加强大的功能。这种技术对应于一种被称之为装饰模式的设计模式。
A公司基于面向对象技术开发了一套图形界面构件库,该构件库提供了大量基本构件,如窗体、文本框、列表框等。由于在使用该构件库时,用户经常要求定制一些特殊的显示效果,如带滚动条的窗体、带黑色边框的文本框、既带滚动条又带黑色边框的列表框等,因此经常需要对该构件库进行扩展以增强功能。如何提高图形界面构件库的可扩展性并降低其维护成本是A公司开发人员必须面对的一个问题。
开发人员针对上述要求,提出了一个基于继承复用的初始设计方案,基本结构如下:
上图中,在抽象类Component中声明了抽象方法 Display(),其子类 Window、TextBox、ListBox等实现了 Display() 方法,可以显示最简单的控件,再通过它们的子类来对功能进行扩展。比如Window下边的 SrollBarWindow、BlackBorderWindow中对Window中的Display()方法进行扩展,分别实现了带滚动条和带黑色边框的窗体。但是仔细分析发现还是存在以下几个问题:
显然这不是一个好的设计方案,根本原因在于复用机制的不合理。如何让系统中的类可以进行扩展但是又不会导致类的数目急剧增加呢?根据合成复用原则,在实现功能复用时,要多用关联,少用继承。接下来就是装饰模式大展身手的时候了,装饰模式,顾名思义,它的作用就是对原有对象进行装饰,通过装饰来扩展原有对象的功能,大大简化系统设计。
装饰模式可以在不改变一个对象本身功能的基础上给对象增加额外的新行为。装饰模式是一种用于替代继承的技术,它通过一种无须定义子类的方式来给对象动态增加职责,使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类,在装饰类中既可以调用待装饰的原有类的方法,还可以增加新的方法,以扩充原有类的功能。装饰模式的定义如下:
装饰模式(Decorator Pattern):动态地给一个对象增加一些额外的职责,就增加对象的功能来说,装饰模式比生成子类实现更为灵活.装饰模式是一种对象结构型模式.
在装饰模式中,为了让系统具有更好的灵活性和可扩展性,通常会定义一个抽象装饰类,而将具体的装饰类作为它的子类。装饰模式的结构如图:
上图中包含4种角色:
由于具体构件类和装饰类都实现了相同的抽象构件接口,因此装饰模式以对客户端透明的方式动态地给一个对象附加上更多的责任。换言之,客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不需要创造更多子类的情况下,将对象的功能加以扩展。
为了让系统具有更好地灵活性和可扩展性,克服继承复用所带来地问题,A公司开发人员使用装饰模式来重构图形界面构件库地设计,其中部分结类地结构如图:
Component 充当抽象构件类,其子类 Window、TextBox、ListBox 充当具体构件类。Component 类的另一个子类 ComponentDecorator 充当抽象装饰类,ComponentDecorator 的子类 ScrollBarDecorator 和 BlackBorderDecorator 充当具体装饰类。完整代码如下:
/// <summary>
/// 抽象界面构件类:抽象构件类。为了突出与模式相关的代码,对原有控件代码进行了大量的简化
/// </summary>
public abstract class Component
{
public abstract void Display();
}
/// <summary>
/// 窗体类:具体构件类
/// </summary>
public class Window : Component
{
public override void Display()
{
Console.WriteLine("显示窗体");
}
}
/// <summary>
/// 文本框类:具体构件类
/// </summary>
public class TextBox : Component
{
public override void Display()
{
Console.WriteLine("显示文本框");
}
}
/// <summary>
/// 列表框类:具体构件类
/// </summary>
public class ListBox : Component
{
public override void Display()
{
Console.WriteLine("显示列表框");
}
}
/// <summary>
/// 构件装饰类:抽象装饰类
/// </summary>
public class ComponentDecorator : Component
{
//位置对抽象构件类型对象的引用
private Component component;
/// <summary>
/// 注入抽象构件类型的对象
/// </summary>
/// <param name="component"></param>
public ComponentDecorator(Component component)
{
this.component = component;
}
public override void Display()
{
component.Display();
}
}
/// <summary>
/// 滚动条装饰类:具体装饰类
/// </summary>
public class SrollBarDecorator : ComponentDecorator
{
public SrollBarDecorator(Component component) : base(component)
{
}
public override void Display()
{
this.SetSsrollBar();
base.Display();
}
public void SetSsrollBar()
{
Console.WriteLine("为构件增加滚动条");
}
}
/// <summary>
/// 黑色边框装饰类:具体装饰类
/// </summary>
public class BlackBorderDecorator : ComponentDecorator
{
public BlackBorderDecorator(Component component) : base(component)
{
}
public override void Display()
{
this.SetBlackBorder();
base.Display();
}
public void SetBlackBorder()
{
Console.WriteLine("为构件增加黑色边框");
}
}
客户端测试代码:
class Program
{
static void Main(string[] args)
{
Component component = new Window();
Component componentSB = new SrollBarDecorator(component);
componentSB.Display();
}
}
输出结果:
如果希望得到一个既有滚动条又有黑色边框的窗体,不需要对原有类库进行任何修改,只需要将客户端代码进行修改如下:
class Program
{
static void Main(string[] args)
{
Component component = new Window();
Component componentSB = new SrollBarDecorator(component);
Component componentBB = new BlackBorderDecorator(componentSB);
componentBB.Display();
}
}
编译并运行:
如果需要在原有系统中增加一个新的具体构件类或者新的具体装饰类,无需修改现有类库代码,只需将他们分别作为抽象构件类或者抽象装饰类的子类即可。与继承结构相比,使用装饰模式之后大大减少了子类的个数,让系统扩展起来更加方便,而且更容易维护。装饰模式是取代继承复用的有效方式之一。
在使用装饰模式时,通常需要注意以下几个问题:
装饰模式降低了系统的耦合度,可以动态的增加或删除对象的职责,并使得需要装饰的具体构件类和具体装饰类独立变化,以便增加新的具体构件类和具体装饰类。
https://github.com/crazyliuxp/DesignPattern.Simples.CSharp