【IT168 技术文章】
前言：XP中有个准则，就是只做目前你需要做的。例如，我需要加法运算，你就没有必要实现乘法运算，因为这不是客户需要的。因此，在开发中，我们可以不去考虑程序对于未来的扩展性。“简单最好！”那么，是否就不需要设计了呢？至于设计模式，是否也可以不去了解了呢？答案至少是否定的。因为客户的需求是“与时俱进”的，现在不实现，并不等于今后不实现。在实现中，不管是重构，还是重新设计，通过应用设计模式，能令你如虎添翼。关键不在于设计模式是否重要，而在于你怎么应用它，以及选择什么样的时机。总而言之，设计，由你掌握！
一、从需求开始
在我们的项目中，作费用结算的时候，客户要求将该过程与结果写入到日志文件中。不过他们的要求很善良，只需要知道日志记录结算开始与结束的时间而已。是的，按照XP的理念，我们只需要做好客户需要的事情就OK了。既然是这样，事情就好办，代码轻易而举就实现了：
public class Fee
{
//结算程序将调用数据层的相关方法，访问数据库；
//为简单起见，我用累加数取代；
public double SettleFee(double money,int records)
{
double result = 0.0;
//我用控制台输出来表示写日志；
Console.WriteLine(”Start settling fee at {0}”,DateTime.Now);
for (int i=0;i {
result+=money;
}
Console.WriteLine(”Settling fee finished at {0}”,DateTime.Now);
return result;
}
}
写好这个，还差点什么？不错，我们还需要为Fee类撰写相应的测试代码，做好单元测试。可能对于传统的程序员来说，更喜欢的是在编码完成后，再根据测试计划编写测试样例，最后测试。但敏捷开发的要求却是测试先行，单元测试是必不可少的环节。不过，我认为单元测试毕竟只是一种手段。我们在实际的项目开发中，对于单元测试不可拘泥教科书的要求，按部就班地一步一步进行；而应该根据实际情况，比如开发者对语言的掌握程度，对设计的理解等等，来决定你单元测试的步骤，乃至于重构的步伐。
[TestFixture]
public class TestFee
{
[Test]
pubic void Settle()
{
Fee fee = new Fee();
Assert.IsNotNull(fee);
Assert.AreEqual(6,fee.SettleFee(2.0,3));
}
}
在NUnit中打开这个测试类，并运行。毫无疑义，你会看到测试的绿灯全部都亮了。你可以在NUnit中看看控制台输出的结果。自然你也可以在AreEqual()方法中，故意将预期的值设置错误，来看看运行NUnit是什么情况，以及出现的错误提示信息。不过，这些都不是本文关注的重点。
二、当需求改变了
在XP中，客户的重要是举足轻重的。在客户提出需求的时候，你需要和他尽可能地沟通，并保证意见最后要达成一致。然而客户对产品的理解可能有时候会出现偏差，也许有时候对方的要求也会随着产品的应用而逐渐发生改变。所幸的是，这一次需求的改变，发生在项目开发过程中，且是在你和他结对交流的时候，最终发现的缺陷。因为客户认为，这个日志过于简单了，并不利于今后对产品的维护。我得承认这是一个好的要求。
事实上，日志记录得越详细，对于开发人员自己也是有好处的。最后，我们决定，日志不仅仅要记载结算的起止时间，还应该记载可能会出现的错误信息，最好还能记载这个结算的过程代码，比如我们执行的是哪一个存储过程，读取了哪些表的数据，包括这些表的字段。
然而有个不利的因素是，这个费用结算的过程可能会很频繁的使用。如果写入的日志太复杂了，会否影响产品的性能？而且频繁写日志的话，日志文件会不会越来越大？如果我们这个产品已经非常健壮，还有必要去记载这些信息吗？毕竟有很多信息，对于普通用户而言，并没有实际用处，反而干扰了他有效获取日志的有用信息。
所以后来我们想到一个方法，就是将日志进行分级，从最简单到最详尽。用户在进行费用结算的时候，可以根据自身需要，选择日志的级别。无疑，这是一个令人满意的策略。
三、如果不熟悉设计模式
假设我们的开发人员对于设计模式一概不知，经过分析客户的需求，他会直接了当的做出如此的解决方案。首先定义三种级别的日志：SimplestLog，NormalLog，DetailedLog。SimplestLog只记录结算的起止时间和耗费的时间，同时还要记录结算后的结果。NormalLog则除此之外，还要记录可能会出现的错误信息。而DetailedLog最详尽，它不仅包含了NormalLog记录的信息，还包括记录结算的实现方法，如用到的存储过程，数据表和相应的字段。
我们最初设想为这三种级别建立三个不同的私有方法，然后在SettleFee()方法中，引入一个日志级别参数，然后根据日志级别的值，决定调用哪一个私有方法，例如：
private void WriteSimplestLog();
private void WriteNormalLog();
private void writeDetailedLog();
public enum LogLevelEnum{Simple=0,Normal,Detail};
public double SettleFee(double money,int records,LogLevelEnum logLevel)
{
switch (logLevel)
{
case LogLevel.Simple:
WriteSimplestLog();
break;
case LogLevel.Normal:
WriteNormalLog();
break;
case LogLevel.Detail:
writeDetailedLog();
break;
}
for (int i=0;i {
result+=money;
}
}
不用说，我们的程序员遇到麻烦了。因为在记录日志信息的时候，可能会在结算的前后来进行。也就是说，结算的那一段代码必须放到记录日志的方法中，才可以实现。幸运的是，我们的程序员应该还具备重构的知识，他决定把结算的那一段代码专门抽取出来，形成一个单独的方法，再放到日志方法中调用。“Extract Method”，不是吗？很聪明的做法。
好吧，我们来实现它吧，看看会是怎样？
首先，实现专门的结算方法：
private double Settle(double money,int records)
{
double result = 0.0;
for (int i=0;i {
result+=money;
}
return result;
}
再来实现日志方法：
private void WriteSimplestLog()
{
DateTime startTime,endTime;
startTime = DateTime.Now;
Console.WriteLine(”Start settling fee at {0}”,startTime);
result = Settle(money,records);
endTime = DateTime.Now;
Console.WriteLine(”Settling fee finished at {0}”,endTime);
TimeSpan wasted = endTime - startTime;
Console.WriteLine(”It wasted time {0}”,wasted);
Console.WriteLine(”The result is {0}”,result);
}
在这个方法中，result是Fee类中的一个私有变量，用来保存结算后的结果。假 设不使用这个变量，而是在方法中引入局部变量，那么WritesimplestLog()方法就必须返回double类型了，这个设计可够糟糕的！同样的，money和records也应该是通过私有变量传递值，否则这个日志方法就必须带上这两个参数了。
接着实现下面两个方法。我们已经注意到根据日志级别的不同，最详尽的日志内容总是包含了其低一级日志的内容。并且，后两级日志没有包括性能的记录，因此记录的日志并未要求必须出现在结算方法的前后。
private void WriteNormalLog()
{
try
{
WriteSimplestLog();
Console.WriteLine(”Settling operation succeed!”);
}
catch (Exception ex)
{
Console.WriteLine(”The error occured while settling the fee.”);
Console.WriteLine(”The error is ” + ex.Message);
}
}
private void WriteDetailedLog()
{
WriteNormalLog();
Console.WriteLine(”The StoreProcedure whick was invoked is SpSettleFee.”);
Console.WriteLine(”Data table is: UserFee, OnLineRecord.”);
}
剩下的代码就简单了：
private double result = 0.0;
private doulbe money = 0.0;
private int record = 0;
public double SettleFee(double money,int records,LogLevelEnum logLevel)
{
this.money = money;
this.record = record;
switch (logLevel)
{
case LogLevel.Simple:
WriteSimplestLog();
break;
case LogLevel.Normal:
WriteNormalLog();
break;
case LogLevel.Detail:
writeDetailedLog();
break;
}
return result;
}
嘿嘿，看起来还不错！
当然，与之相应的测试代码也要发生改变：
[Test]
pubic void Settle()
{
Fee fee = new Fee();
Assert.IsNotNull(fee);
Assert.AreEqual(6,fee.SettleFee(2.0,3,LogLevelEnum.Simple));
Assert.AreEqual(6,fee.SettleFee(2.0,3,LogLevelEnum.Normal));
Assert.AreEqual(6,fee.SettleFee(2.0,3,LogLevelEnum.Detail));
}
四、问题又出现了
我们程序员都应该有这个信仰，就是：简单最好。我不喜欢那些常常卖弄自己水平的人，仅仅为了一个简单的要求，却故意把代码弄得非常复杂，以为卖弄高深就是学问。其实不然。我倾向于简单的算法，即使它的性能稍差。因为性能差，我们还可以通过提升硬件等多种方式来解决；而如果整个项目都充斥着难于理解的算法，想一想，如果写代码的“牛人”走了，而目前又需要对程序做改进。那么，项目的后任者，在deadline的压力下，面对这一大堆“高深”的算法，会是怎样的抓狂！？
所以，从目前来看，以上实现的代码并没有什么不合适的地方。简单易懂，也完成了客户的需求。不过，很多时候事情并非尽如人意。客户的需求会随着对项目的跟进，而逐渐发生改变。
一周后，我们的客户提出了新的要求。首先，他希望这个日志功能，能够展现它更灵活的一面。不是死板的从最简单到最详尽，而是根据日志记载的内容，任意灵活的组合。原来的日志层次如图一：
图一：最简单的日志组合
而根据现在的需求，可能会有多种组合：
图二：灵活的组合，日志变得多种多样
我们算一算，如果按照前面的方式来实现新的需求，可能会写出多少个方法？此时的你应该怎样办呢？
或许应该将逻辑抽象出来，为日志建立一个基类；然后根据实际的需求派生不同的子类。在调用的时候，可以通过多态的方式，决定调用何种具体的日志对象方法。
但是问题接踵而至。首先是写日志方法和费用结算方法如何结合起来？尤其是A类日志，写日志的时候必须是在费用结算的前后，以确定结算的起止时间。也许，我们可以考虑将该方法分离为两个方法BeforeWriteLog()和AfterWriteLog()。那么与之对应的，凡是和A类日志有关的其他日志，也必须实现这种分离策略。再想想继承的子类，根据日志这种灵活的组合，我们需要创建多少个子类对象。一旦需求再增加呢？这个无底洞我是不愿意去跳的。
而客户的要求并没有结束。他还需要在与费用有关的其他方法中，也实现日志的功能。例如费用查询。由于之前的策略是在日志方法中包含费用结算的功能。如果需要记录费用查询的日志，岂不是要为它再建立不同的日志方法？
总之，如果你不了解设计模式的话，你可能会非常棘手。你会用尽所有已掌握的知识，通过你对OOP的理解，使用接口，继承和聚合，最后你可能会发现你碰壁了。乐观的是，你最终解决了问题。可是看看解决方案呢？要么拙劣不忍目睹，要么幸运的是你采用了正确的策略。你已经达到了GOF的水平，自己创造出我们应该正确使用的模式了。不过，可惜的是，你会沮丧地听到，有人会告诉你，你采用的其实就是设计模式中的Decorator模式。与其这样，为什么不好好地学习一下设计模式呢？
五、结果完全不一样了
如果你已经熟悉了设计模式的话，面对客户提出的新的需求，你就会很快获得完美的解决方案了。
分析一下。虽然日志的级别会非常之多，但其根本的功能却是一致的，那就是所有的日志信息都是费用结算（自然也包括费用查询）的包装而已。形象地说，日志就好比油漆工人，而费用结算就是一间房子，需要油漆工人来给墙壁粉刷上美丽的色彩。如此而已。
修改后的结构类图如下：
此时，我将原来的日志方法修改为单独的类对象。同时将日志由原来分级(Simplest, Normal, Detailed)的方式，改为按各自的功能划分，然后建立日志对象(BasicLogDecorator,ErrorLogDecorator,ImplLogDecorator)。具体的修改思路和步骤，如第六部分描述。
在使用Decorator模式来实现如上需求之前，我想表明自己的态度：
1、 设计模式的重要性已经不言而喻了；
2、 不要为了模式而去学习模式，设计模式必须和项目实际开发结合；
3、 如果目前的需求很简单，不用设计模式并不是一个坏的选择；
4、 因为我们有重构；
5、 但必须记住，重构的每一步，需要以单元测试来保证；
6、 你必须深入理解设计模式，否则当需求复杂之后，你会束手无策；
7、 设计模式是人创造出来的，但既然已经有了前人的成果，为什么不用？
写到这里，诸位已经可以结束本文的阅读了。不过我还得继续下去，作业没有做完，不能交卷。
六、大结局
因为现在的需求比较复杂了，所以你在重构每一步时，必须小心翼翼。别忘了单元测试，有了它，才可以保证你的正确无误。
首先，利用“Extract Interface”原则，为装饰的对象Fee类Extract一个接口，并让Fee类实现它：
public interface IFee
{
double SettleFee(double money, int records);
}
public class Fee:IFee {}
当然，我们需要把SettleFee()方法恢复成原来的模样。记住这个过程仍然需要小心翼翼。因为，在实现这一步时，可能已经离最初的简单实现已经有一周的时间了。所以，再恢复原样的过程中，我希望仍然不要放弃使用单元测试。当然在这里，我为了行文简洁，省略了这些过程。
修改测试代码，然后在NUnit中运行它：
[Test]
pubic void Settle()
{
IFee fee = new Fee();
Assert.IsNotNull(fee);
Assert.AreEqual(6,fee.SettleFee(2.0,3));
}
现在来分析日志。根据对前面A类、B类、C类日志的分析。我们不再从是否详尽的角度来分类日志，而是从日志的内容或者说日志实现的功能来分类。我们可以将日志分为基本日志类、错误日志类、实现日志类三种。
基本日志类：实现日志的基本功能，包括费用结算的耗时和结算后的结果。
错误日志类：记录可能会出现的错误消息。
实现日志类：将费用结算的具体实现记录下来，便于以后对于产品的维护。
因为日志就是Decorator模式的油漆工，它们都需要具备包装费用结算的功能，我为它们定义了一个共同的抽象类：
public abstract class LogDecorator
{
privated IFee decoratee;
public LogDecorator(IFee decoratee)
{
this.decoratee = decoratee;
}
public IFee Decoratee
{
get {return this.decoratee;}
}
}
基本日志类、错误日志类、实现日志类都继承该抽象类。注意抽象类的自定义构造函数，它是实现装饰功能的关键。该构造函数负责传递一个被装饰的对象进来，并赋给属性Decoratee。这个初始化的过程，就好比刷油漆的刷子，对于所有油漆工人来说，都应该是一样的，只是他们刷的油漆不同而已。
要装饰Fee类，仅仅依靠构造函数来传递被装饰对象还不够。我们还需要把原来Fee类所做的工作，转移到装饰类中，如此才能完成装饰的功用。所以，这三个日志类，不仅要继承LogDecorator类，还需要实现IFee接口，即与Fee类实现同一个接口。
首先是基本日志类：
public class BasicLogDecorator:LogDecorator,IFee
{
public BasicLogDecorator(IFee decoratee):base(decoratee) {}
public double SettleFee(double money,int records)
{
DateTime startTime,endTime;
startTime = DateTime.Now;
Console.WriteLine(”Start settling fee at {0}”,startTime);
double result = Decoratee.SettleFee(money,records);
endTime = DateTime.Now;
Console.WriteLine(”Settling fee finished at {0}”,endTime);
TimeSpan wasted = endTime - startTime;
Console.WriteLine(”It wasted time {0}”,wasted);
Console.WriteLine(”The result is {0}”,result);
return result;
}
}
做到这一步时，先别急着去实现另外两个类。我们应该先做单元测试。修改单元测试代码：
[Test]
pubic void SettleBasicLog()
{
IFee fee = new Fee();
IFee basicLogFee = new BasicLogDecorator(fee);
Assert.IsNotNull(fee);
Assert.IsNotNull(basicLogFee);
Assert.AreEqual(6,fee.SettleFee(2.0,3));
Assert.AreEqual(6, basicLogFee.SettleFee(2.0,3));
}
不过这个单元测试代码似乎有点乱，我们应该根据具体的实现，对测试方法分类，同时将类对象的初始化放到[SetUp]中。因此，新的测试代码如下：
[TestFixture]
public class TestFee
{
[TestFixture]
public class TestFee
{
private IFee fee;
[SetUp]
public void Init()
{
fee = new Fee();
}
[Test]
[Category(”SettleWithoutLog”)]
public void Settle()
{
Assert.IsNotNull(fee);
Assert.AreEqual(6,fee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasicLog”)]
public void SettleBasicLog()
{
IFee basicLogFee = new BasicLogDecorator(fee);
Assert.IsNotNull(basicLogFee);
Assert.AreEqual(6,basicLogFee.SettleFee(2.0,3));
}
[TearDown]
public void Dispose()
{
/*—*/
}
}
}
通过Category对测试方法进行分类（也可以对测试类进行分类）。这样，我们就可以在Nunit中，根据测试的情况，选择要测试的分类，或Exclude（排除）不测试的分类。我们运行一下，看NUnit的绿灯是否都亮了？测试通过后，就可以接着实现另外的日志类了。
public class ErrorLogDecorator:LogDecorator,IFee
{
public ErrorLogDecorator(IFee decoratee):base(decoratee){}
public double SettleFee(double money, int records)
{
try
{
double result = Decoratee.SettleFee(money,records);
Console.WriteLine(”Settling operation succeed!”);
return result;
}
catch (Exception ex)
{
Console.WriteLine(”The error occured while settling the fee.”);
Console.WriteLine(”The error is ” + ex.Message);
return 0;
}
}
}
public class ImplLogDecorator:LogDecorator,IFee
{
public ImplLogDecorator(IFee decoratee):base(decoratee)
{}
public double SettleFee(double money, int records)
{
double result = Decoratee.SettleFee(money,records);
Console.WriteLine(”The StoreProcedure whick was invoked is SpSettleFee.”);
Console.WriteLine(”Data table is: UserFee, OnLineRecord.”);
return result;
}
}
当然每做一步改进后，都需要修改测试代码进行单元测试。最后的单元测试代码：
using System;
using NUnit.Framework;
using FeeManagement;
namespace UnitTest
{
[TestFixture]
public class TestFee
{
private IFee fee;
[SetUp]
public void Init()
{
fee = new Fee();
}
[Test]
[Category(”SettleWithoutLog”)]
public void Settle()
{
Assert.IsNotNull(fee);
Assert.AreEqual(6,fee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasicLog”)]
public void SettleBasicLog()
{
IFee basicLogFee = new BasicLogDecorator(fee);
Assert.IsNotNull(basicLogFee);
Assert.AreEqual(6,basicLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithErrorLog”)]
public void SettleErrorLog()
{
IFee errorLogFee = new ErrorLogDecorator(fee);
Assert.IsNotNull(errorLogFee);
Assert.AreEqual(6,errorLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithImplLog”)]
public void SettleImplLog()
{
IFee implLogFee = new ImplLogDecorator(fee);
Assert.IsNotNull(implLogFee);
Assert.AreEqual(6,implLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasic&ErrorLog”)]
public void SettleBasicErrorLog()
{
IFee basicLogFee = new BasicLogDecorator(fee);
IFee errorLogFee = new ErrorLogDecorator(basicLogFee);
Assert.IsNotNull(basicLogFee);
Assert.IsNotNull(errorLogFee);
Assert.AreEqual(6,errorLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasic&ImplLog”)]
public void SettleBasicImplLog()
{
IFee basicLogFee = new BasicLogDecorator(fee);
IFee implLogFee = new ImplLogDecorator(basicLogFee);
Assert.IsNotNull(basicLogFee);
Assert.IsNotNull(implLogFee);
Assert.AreEqual(6,implLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithAllLog”)]
public void SettleAllLog()
{
IFee basicLogFee = new BasicLogDecorator(fee);
IFee implLogFee = new ImplLogDecorator(basicLogFee);
IFee errorLogFee = new ErrorLogDecorator(implLogFee);
Assert.IsNotNull(basicLogFee);
Assert.IsNotNull(implLogFee);
Assert.IsNotNull(errorLogFee);
Assert.AreEqual(6, errorLogFee.SettleFee(2.0,3));
}
[TearDown]
public void Dispose()
{
/*—*/
}
}
}
由于每一步都严格进行了单元测试，所以，我们对代码的正确性充满了信心。这也是单元测试的重要性及必要性所在。
七、真的结束了吗
从测试代码中看出，目前的解决方案还存在一个问题，就是日志对象的创建。由于日志对象可能会根据不同的情况，组合成不同的对象。如果不采取相应的方法来解决对象创建的问题，可能会造成对象管理的混乱。因此，我们还有必要引入工厂模式，专门负责日志对象的创建。
我最初考虑在工厂方法中，将这些日志类型放到一个Type[]数组中，然后再通过反射的方式创建对象。然而，由于创建日志对象的组合会很麻烦，采用这样的设计，反而会有过度设计的嫌疑。（这也是我为什么在Decorator类中使用构造函数而非采用专门的方法来设置Decoratee对象的原因。）
所以，只需要直接根据日志的情况为其分别创建相关的工厂方法就可以了。
public class DecoratorFactory
{
private static IFee fee = new Fee();
public static IFee CreateFee()
{
return fee;
}
public static IFee CreateBasicLogFee()
{
IFee basicLog = new BasicLogDecorator(fee);
return basicLog;
}
public static IFee CreateErrorLogFee()
{
IFee errorLog = new ErrorLogDecorator(fee);
return errorLog;
}
public static IFee CreateImplLogFee()
{
IFee implLog = new ImplLogDecorator(fee);
return implLog;
}
public static IFee CreateBasicErrorLogFee()
{
IFee basicLog = new BasicLogDecorator(fee);
IFee errorLog = new ErrorLogDecorator(basicLog);
return errorLog;
}
public static IFee CreateBasicImplLogFee()
{
IFee basicLog = new BasicLogDecorator(fee);
IFee implLog = new ImplLogDecorator(basicLog);
return implLog;
}
public static IFee CreateAllLogFee()
{
IFee basicLog = new BasicLogDecorator(fee);
IFee implLog = new ImplLogDecorator(basicLog);
IFee errorLog = new ErrorLogDecorator(implLog);
return errorLog;
}
}
然后再修改NUnit的测试代码：
[TestFixture]
public class TestFee
{
private IFee fee;
[SetUp]
public void Init()
{
fee = DecoratorFactory.CreateFee();
}
[Test]
[Category(”SettleWithoutLog”)]
public void Settle()
{
Assert.IsNotNull(fee);
Assert.AreEqual(6,fee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasicLog”)]
public void SettleBasicLog()
{
IFee basicLogFee = DecoratorFactory.CreateBasicLogFee();
Assert.IsNotNull(basicLogFee);
Assert.AreEqual(6,basicLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithErrorLog”)]
public void SettleErrorLog()
{
IFee errorLogFee = DecoratorFactory.CreateErrorLogFee();
Assert.IsNotNull(errorLogFee);
Assert.AreEqual(6,errorLogFee.SettleFee(2.0,3));
}
[Test]
[ Category(”SettleWithImplLog”)]
public void SettleImplLog()
{
IFee implLogFee = DecoratorFactory.CreateImplLogFee();
Assert.IsNotNull(implLogFee);
Assert.AreEqual(6,implLogFee.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasic&ErrorLog”)]
public void SettleBasicErrorLog()
{
IFee log = DecoratorFactory.CreateBasicErrorLogFee();
Assert.IsNotNull(log);
Assert.AreEqual(6,log.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithBasic&ImplLog”)]
public void SettleBasicImplLog()
{
IFee log = DecoratorFactory.CreateBasicImplLogFee();
Assert.IsNotNull(log);
Assert.AreEqual(6,log.SettleFee(2.0,3));
}
[Test]
[Category(”SettleWithAllLog”)]
public void SettleAllLog()
{
IFee log = DecoratorFactory.CreateAllLogFee();
Assert.IsNotNull(log);
Assert.AreEqual(6,log.SettleFee(2.0,3));
}
[TearDown]
public void Dispose()
{
/*—*/
}
}
经过这么多阶段的修改和完善，目前看来解决方案已经比较完善了。如果在Fee类中还有其他的方法，需要日志功能，方法仍然大同小异。因为在C#中可以同时实现多个接口，如果实现其他接口的类也要增加该日志功能，则日志的Decorator类同时还要去实现这个新的接口。好处是，你只需要修改这些实现，而调用的代码，却不用作大的修改了。因为要求提供日志功能的需求可能会不断增加，但只要日志的种类不变，用作装饰功能的日志对象个数就不会改变。
自然，本文讨论日志功能是完全站在OOP的角度来考虑的。如果引入AOP的思想，将日志看作是一个方面(Aspect)，那么对于客户而言，可能会更简单。但这已不是本文要讨论的问题了。
