Decorator--装饰器模式浅见

using System;
using System.Text;

using System.Collections.Generic;
using System.Data.Linq;
using System.Data.Linq.SqlClient;

namespace Test
{
    class Clock //基类 所有派生于此类的类 必须要有Get方法
    {
        public virtual string Get()
        {
            return "The time is";
        }
    }
    
    class ClockDecorator : Clock //装饰类 用以装饰基类及其派生类
    {
        private Clock _clock;
        public ClockDecorator(Clock clock)
        {
            this._clock=clock;
        }
        
        public override string Get ()
        {
            return this._clock.Get();
        }
    }
    
    class AddString : ClockDecorator //装饰器子类 用以给基类或其派生类添加新职责
    {
        public AddString(Clock clock):base(clock)
        {
            
        }
        
        public override string Get ()
        {
            string s=base.Get ();
            return s+" "+DateTime.Now.ToString();
        }
    }
    
    class Program
    {
        public static void Main()
        {
            Clock c=new Clock();
            ClockDecorator cd=new AddString(c);
            Console.WriteLine(cd.Get());
        }
    }
}

　　上面写的code，简单的用来实现了对clock类对象的“装饰”。

　　所谓装饰，就是在不改变原有类的基础上，在外部给此类添加一些职责功能。可以创建很多装饰器子类，用来给基类装饰。而不用继承子类的方式，这样做的好处是可以避免过多的子类，以上的代码可能对“有效避免子类”难免会有岐义，那么来扩充下：

using System;
using System.Text;

namespace Test
{
    abstract class ClockBase
    {
        public abstract string Get();
    }
    
    class Clock : ClockBase
    {
        public override string Get()
        {
            return "The time is";
        }
    }
    
    class ClockDecorator : ClockBase
    {
        private Clock _clock;
        public ClockDecorator(Clock clock)
        {
            this._clock=clock;
        }
        
        public override string Get ()
        {
            return this._clock.Get();
        }
    }
    
    class AddString : ClockDecorator
    {
        public AddString(Clock clock):base(clock)
        {
            
        }
        
        public override string Get ()
        {
            string s=base.Get ();
            return s+" "+DateTime.Now.ToString();
        }
    }
    
    class Program
    {
        public static void Main()
        {
            Clock c=new Clock();
            ClockDecorator cd=new AddString(c);
            Console.WriteLine(cd.Get());
        }
    }
}

　　这里Clock和ClockDecorator有一个共通的基类ClockBase，并共有一个必须要实现的抽象方法，在主程序中，实例化一个要添加对象职责的类Clock，并定义一个装饰器对象，并用装饰器子类来实例化此对象，装饰器子类有个构造函数，并把Clock实例对象添加到构造函数中去，那么此时可以说cd对象，在一定程度上，就是c对象经过了装饰后的对象，当然了，如果用对象标识来确定对象的划分的话，cd对象不是c对象，虽然他们拥有一个共通的基类和方法。

　　此时运行以上代码，可以看到会输出原本在Clock中并没有包含的东西，也就是具体的时间是在装饰过后才有的。

　　当然想要扩充对象的功能，可以用继承，但是请设想以下，一个基类有很多个子类，如果要给每个子类添加一个或几个很少用到的功能，那么就又要生成很多个子类的子类。如果采用装饰器模式，那么尽管它有很多子类，那么我只要包装其生成的对象，就可以给此对象，添加不止一个功能，但是写的子类确实大大的减少了要生成的子类的子类。

　　以上说的都是装饰器的优点，可以减少子类的产生，而且用来扩充功能的装饰器子类，可以很专一的负责一个职责，而要添加几个职责，那么就可以采用生成相应的，功能单一的装饰器子类来装饰要装饰的对象。而且可以在执行原有对象的前后，添加一些其他的功能，比如说日志记录，系统状态输出，输出提示值等相应的功能。因为装饰器子类都是从装饰器类派生出来的，那么就可以对相应的方法进行嵌套，来达到按照一定的流程来进行一定的流程化操作。

　　装饰器模式的缺点。事物都有两面性，所以有好就有不好的地方。它的主要缺点，一是此对象非彼对象，也就是上面例子中的cd和c，追根纠底不是完全一样的对象标识！二是，在实例化装饰器子类实会产生相应的对象，这样会导致要添加的职责越多，越要生成越多的装饰器子类对象，比较难以控制。

　　

　　所以任何模式，过犹不及是真理，要适度，比如在较少使用某个功能，而类本身却缺少的此功能的情况下，但是这些功能不依赖于类本身，如果要派生子类的话，会有杂乱而且不合适，造成维护困难，并违反单一职责原则，那么就我目前的水平来说，我会考虑用此模式来适当的扩充对象职责。

　　有任何错误或失实之处，恳请评论批评。