前言：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<records;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<records;i++)

{

result+=money;

}

}

不用说，我们的程序员遇到麻烦了。因为在记录日志信息的时候，可能会在结算的前后来进行。也就是说，结算的那一段代码必须放到记录日志的方法中，才可以实现。幸运的是，我们的程序员应该还具备重构的知识，他决定把结算的那一段代码专门抽取出来，形成一个单独的方法，再放到日志方法中调用。“Extract Method”，不是吗？很聪明的做法。

好吧，我们来实现它吧，看看会是怎样？

首先，实现专门的结算方法：

private double Settle(double money,int records)

{

double result = 0.0;

for (int i=0;i<records;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 LogLevelEnum.Simple:

WriteSimplestLog();

break;

case LogLevelEnum.Normal:

WriteNormalLog();

break;

case LogLevelEnum.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)，那么对于客户而言，可能会更简单。但这已不是本文要讨论的问题了。