封装的变化之封装对象创建的变化

下载本文示例代码
　　考虑一个日志记录工具。目前需要提供一个方便的日志API，使得客户可以轻松地完成日志的记录。该日志要求被记录到指定的文本文件中，记录的内容属于字符串类型，其值由客户提供。我们可以非常容易地定义一个日志对象： public class Log{　public void Write(string target, string log) 　{　　//实现内容;　}}　　当客户需要调用日志的功能时，可以创建日志对象，完成日志的记录： Log log = new Log();log.Write(“error.log”, “log”);　　然而随着日志记录的频繁使用，有关日志的文件越来越多，日志的查询与管理也变得越不方便。此时，客户提出，需要改变日志的记录方式，将日志内容写入到指定的数据表中。显然，如果仍然按照前面的设计，具有较大的局限性。 现在我们回到设计之初，想象一下对于日志API的设计，需要考虑到这样的变化吗？这里存在两种设计理念，即渐进的设计和计划的设计。从本例来分析，要求设计者在设计初就考虑到日志记录方式在未来的可能变化，并不容易。再者，如果在最开始就考虑全面的设计，会产生设计上的冗余。因此，采用计划的设计固然具有一定的前瞻性，但一方面对设计者的要求过高，同时也会产生一些缺陷。那么，采用渐进的设计时，遇到需求变化时，利用重构的方法，改进现有的设计，又需要考虑未来的再一次变化吗？这是一个见仁见智的问题。对于本例而言，我们完全可以直接修改Write()方法，接受一个类型判断的参数，从而解决此问题。但这样的设计，自然要担负因为未来可能的再一次变化，而导致代码大量修改的危险，例如，我们要求日志记录到指定的Xml文件中。　　所以，变化是完全可能的。在时间和技术能力允许的情况下，我更倾向于将变化对设计带来的影响降低到最低。此时，我们需要封装变化。　　在封装变化之前，我们需要弄清楚究竟是什么发生了变化？从需求看，是日志记录的方式发生了变化。从这个概念分析，可能会导致两种不同的结果。一种情形是，我们将日志记录的方式视为一种行为，确切的说，是用户的一种请求。另一种情形则从对象的角度来分析，我们将各种方式的日志看作不同的对象，它们调用接口相同的行为，区别仅在于创建的是不同的对象。前者需要我们封装“用户请求的变化”，而后者需要我们封装“日志对象创建的变化”。　　封装“用户请求的变化”，在这里就是封装日志记录可能的变化。也就是说，我们需要把日志记录行为抽象为一个单独的接口，然后才分别定义不同的实现。如图一所示： 图一：封装日志记录行为的变化　　如果熟悉设计模式，可以看到图一所表示的结构正是Command模式的体现。由于我们对日志记录行为进行了接口抽象，用户就可以自由地扩展日志记录的方式，只需要实现ILog接口即可。至于Log对象，则存在与ILog接口的弱依赖关系： public class Log{　private ILog log;　public Log(ILog log)　{　　this.log = log;　}　public void Write(string target, string logValue)　{　　log.Execute(target, logValue);　}}　　我们也可以通过封装“日志对象创建的变化”实现日志API的可扩展性。在这种情况下，日志会根据记录方式的不同，被定义为不同的对象。当我们需要记录日志时，就创建相应的日志对象，然后调用该对象的Write()方法，实现日志的记录。此时，可能会发生变化的是需要创建的日志对象，那么要封装这种变化，就可以定义一个抽象的工厂类，专门负责日志对象的创建，如图二所示： 图二：封装日志对象创建的变化　　图二是Factory Method模式的体现，由抽象类LogFactory专门负责Log对象的创建。如果用户需要记录相应的日志，例如要求日志记录到数据库，需要先创建具体的LogFactory对象： LogFactory factory = new DBLogFactory();　　当在应用程序中，需要记录日志，那么再通过LogFactory对象来获取新的Log对象： Log log = factory.Create();log.Write(“ErrorLog”, “log”);　　如果用户需要改变日志记录的方式为文本文件时，仅需要修改LogFactory对象的创建即可： LogFactory factory = new TxtFileLogFactory();　　为了更好地理解“封装对象创建的变化”，我们再来看一个例子。假如，我们需要设计一个数据库组件，它能够访问微软的Sql Server数据库。根据ADO.Net的知识，我们需要使用如下的对象：SqlConnection, SqlCommand, SqlDataAdapter等。　　如果仅就Sql Server而言，在访问数据库时，我们可以直接创建这些对象： SqlConnection connection = new SqlConnection(strConnection);SqlCommand command = new SqlCommand(connection);SqlDataAdapter adapter = new SqlDataAdapter();　　如果在一个数据库组件中，充斥着如上的语句，显然是不合理的。它充满了僵化的坏味道，一旦要求支持其他数据库时，原有的设计就需要彻底的修改，这为扩展带来了困难。共2页。 1 2 : 　　考虑一个日志记录工具。目前需要提供一个方便的日志API，使得客户可以轻松地完成日志的记录。该日志要求被记录到指定的文本文件中，记录的内容属于字符串类型，其值由客户提供。我们可以非常容易地定义一个日志对象： public class Log{　public void Write(string target, string log) 　{　　//实现内容;　}}　　当客户需要调用日志的功能时，可以创建日志对象，完成日志的记录： Log log = new Log();log.Write(“error.log”, “log”);　　然而随着日志记录的频繁使用，有关日志的文件越来越多，日志的查询与管理也变得越不方便。此时，客户提出，需要改变日志的记录方式，将日志内容写入到指定的数据表中。显然，如果仍然按照前面的设计，具有较大的局限性。 现在我们回到设计之初，想象一下对于日志API的设计，需要考虑到这样的变化吗？这里存在两种设计理念，即渐进的设计和计划的设计。从本例来分析，要求设计者在设计初就考虑到日志记录方式在未来的可能变化，并不容易。再者，如果在最开始就考虑全面的设计，会产生设计上的冗余。因此，采用计划的设计固然具有一定的前瞻性，但一方面对设计者的要求过高，同时也会产生一些缺陷。那么，采用渐进的设计时，遇到需求变化时，利用重构的方法，改进现有的设计，又需要考虑未来的再一次变化吗？这是一个见仁见智的问题。对于本例而言，我们完全可以直接修改Write()方法，接受一个类型判断的参数，从而解决此问题。但这样的设计，自然要担负因为未来可能的再一次变化，而导致代码大量修改的危险，例如，我们要求日志记录到指定的Xml文件中。　　所以，变化是完全可能的。在时间和技术能力允许的情况下，我更倾向于将变化对设计带来的影响降低到最低。此时，我们需要封装变化。　　在封装变化之前，我们需要弄清楚究竟是什么发生了变化？从需求看，是日志记录的方式发生了变化。从这个概念分析，可能会导致两种不同的结果。一种情形是，我们将日志记录的方式视为一种行为，确切的说，是用户的一种请求。另一种情形则从对象的角度来分析，我们将各种方式的日志看作不同的对象，它们调用接口相同的行为，区别仅在于创建的是不同的对象。前者需要我们封装“用户请求的变化”，而后者需要我们封装“日志对象创建的变化”。　　封装“用户请求的变化”，在这里就是封装日志记录可能的变化。也就是说，我们需要把日志记录行为抽象为一个单独的接口，然后才分别定义不同的实现。如图一所示： 图一：封装日志记录行为的变化　　如果熟悉设计模式，可以看到图一所表示的结构正是Command模式的体现。由于我们对日志记录行为进行了接口抽象，用户就可以自由地扩展日志记录的方式，只需要实现ILog接口即可。至于Log对象，则存在与ILog接口的弱依赖关系： public class Log{　private ILog log;　public Log(ILog log)　{　　this.log = log;　}　public void Write(string target, string logValue)　{　　log.Execute(target, logValue);　}}　　我们也可以通过封装“日志对象创建的变化”实现日志API的可扩展性。在这种情况下，日志会根据记录方式的不同，被定义为不同的对象。当我们需要记录日志时，就创建相应的日志对象，然后调用该对象的Write()方法，实现日志的记录。此时，可能会发生变化的是需要创建的日志对象，那么要封装这种变化，就可以定义一个抽象的工厂类，专门负责日志对象的创建，如图二所示： 图二：封装日志对象创建的变化　　图二是Factory Method模式的体现，由抽象类LogFactory专门负责Log对象的创建。如果用户需要记录相应的日志，例如要求日志记录到数据库，需要先创建具体的LogFactory对象： LogFactory factory = new DBLogFactory();　　当在应用程序中，需要记录日志，那么再通过LogFactory对象来获取新的Log对象： Log log = factory.Create();log.Write(“ErrorLog”, “log”);　　如果用户需要改变日志记录的方式为文本文件时，仅需要修改LogFactory对象的创建即可： LogFactory factory = new TxtFileLogFactory();　　为了更好地理解“封装对象创建的变化”，我们再来看一个例子。假如，我们需要设计一个数据库组件，它能够访问微软的Sql Server数据库。根据ADO.Net的知识，我们需要使用如下的对象：SqlConnection, SqlCommand, SqlDataAdapter等。　　如果仅就Sql Server而言，在访问数据库时，我们可以直接创建这些对象： SqlConnection connection = new SqlConnection(strConnection);SqlCommand command = new SqlCommand(connection);SqlDataAdapter adapter = new SqlDataAdapter();　　如果在一个数据库组件中，充斥着如上的语句，显然是不合理的。它充满了僵化的坏味道，一旦要求支持其他数据库时，原有的设计就需要彻底的修改，这为扩展带来了困难。共2页。 1 2 : 下载本文示例代码


封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化封装的变化之封装对象创建的变化