另外考虑到不同平台的日志记录，对于操作数据库、写入文本文件所调用的方式可能是不一样的，为此对于不同的日志记录方式，我们需要提供各种不同平台上的实现，对上面的类做进一步的设计得到了下面的结构图：


                                   图5
实现代码如下：

public class NDatabaseLog : DatabaseLog

{

    public override void Write(string log)

    {

        //......(.NET平台)Log Database

    }

}


public class JDatabaseLog : DatabaseLog

{

    public override void Write(string log)

    {

        //......(Java平台)Log Database

    }

}


public class NTextFileLog : TextFileLog

{

    public override void Write(string log)

    {

        //......(.NET平台)Log Text File

    }

}


public class JTextFileLog : TextFileLog

{

    public override void Write(string log)

    {

        //......(Java平台)Log TextFile

    }

}

    现在的这种设计方案本身是没有任何错误的，假如现在我们要引入一种新的xml文件的记录方式，则上面的类结构图会变成：



                                                                                              图6

    如图中蓝色的部分所示，我们新增加了一个继承于Log基类的子类，而没有修改其它的子类，这样也符合了开放-封闭原则。如果我们引入一种新的平台，比如说我们现在开发的日志记录工具还需要支持Borland平台，此时该类结构又变成了：



                                              图7

    同样我们没有修改任何的东西，只是增加了两个继承于DatabaseLog和TextFileLog的子类，这也符合了开放-封闭原则。

    但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起Log类变化的原因却有两个，即日志记录方式的变化和日志记录平台的变化；其次是重复代码会很多，不同的日志记录方式在不同的平台上也会有一部分的代码是相同的；再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。上面我们分析的变化只是沿着某一个方向，如果变化沿着日志记录方式和不同的运行平台两个方向变化，我们会看到这个类的结构会迅速的变庞大。