4、惯例优于配置
使用配置文件固然可以解除与具体对象之间的依赖，然而，它带来的良好可扩展性，却是以牺牲系统的可维护性乃至于可靠性为代价的。配置文件很难管理，尤其是在配置信息相对较多的情况下。不管是集中管理还是分散管理，都存在一些与生俱来的缺陷。如果采用集中管理，则配置文件过大，既影响性能，也不能很好地展现配置信息的分类与层次。在.NET中，虽然可以利用对配置文件进行分节，但终究不够直观。采用分散管理，则不同大小的配置文件千头万绪，既会给维护者带来管理的障碍，也不利于部署与使用。使用配置文件尤其不便于调试。开发环境提供的编译期检查，对于配置文件只能是“望洋兴叹”。所谓“差之毫厘，谬以千里”，小小的一个配置项错误，可能会造成难以弥补的巨大损失。为了弥补这些缺陷，许多产品或框架都提供了专门的配置或管理工具，使用直观的UI界面对配置文件进行操作，但繁杂的配置项仍然有可能让使用者望而却步。
惯例优于配置(Convention over Configuration)来源于Ruby On Rails框架的设计理念，也被认为是Rails大获成功的关键因素之一。这里所谓的惯例，可以理解为框架对编程的一些约束，我们可以根据实现制订的默认规则，通过反射技术完成对象的创建，对象的协作，甚至是应用程序的组装。例如在Rails中对MVC模式的实现中，就事先确立了Model、View和Controller的目录结构与命名规范。在这种情况下，我们不需要对元数据进行任何配置。ASP.NET MVC框架同样采纳了惯例优于配置的思想。采用惯例，虽然在一定程度上损失了系统的灵活性，带来的却是良好的可维护性。同时，它仍然可以解除系统与具体对象之间的强耦合关系。
惯例优于配置的技术并不是非常适合于本文中的订单策略示例。不过，在.NET框架中，有关WebRequest对象的创建，却可以改用惯例优于配置的思想来实现。图2是WebRequest对象的继承体系：
图2 WebRequest的类结构
在.NET框架中，创建一个WebRequest实例的方法是调用WebRequest的静态方法Create()
由于，传入的Uri地址其前缀为"http"，因此创建的myRequest对象应该为HttpWebRequest具体对象。如果需要根据不同的Request协议，扩展不同的WebRequest对象，就需要引入一些设计技巧，来解除与具体对象创建的依赖。.NET框架的实现能够达到这样的目的，但非常复杂，这里不提。我想要介绍的是如何利用惯例优于配置来实现WebRequest对象的扩展。利用“惯例优于配置”的思想有一个前提，就是我们要对WebRequest对象的命名规范进行惯例约束。例如，我们规定所有的WebRequest子类对象均由协议名加上“WebRequest”后缀构成。通过解析传入的Uri，可以获得传输协议的名称，之后将它与“WebRequest”连接起来，获得WebRequest子类对象的类名，再利用反射技术创建该对象。在WebRequest类中定义如下的Create()静态方法：
{
if (requestUri == null)
{
throw new ArgumentNullException("requestUri");
}
string prefix = requestUri.Scheme.ToLower();
if (prefix == null)
{
throw new ArgumentNullException("requestUri");
}
if (prefix.Contains(""))
{
prefix = prefix.Replace(".","");
}
StringBuilder typeName = new StringBuilder();
typeName.Append("System.Net.");
typeName.Append(prefix.Substring(0,1).ToUpper());
typeName.Append(prefix.ToLower().Substring(1,prefix.Length - 1));
typeName.Append("WebRequest");
return (WebRequest)Activitor.CreateInstance(
System.Type.GetType(typeName));
}
只要WebRequest的子类对象能够遵循我们的惯例，即该类的类型名符合事先制订的规范，改进后的Create()方法就能够运行良好。以新增Tcp协议的WebRequest对象为例。该协议的Schema为“net.tcp”，因此其类名必须为“NettcpWebRequest”，并放在“System.Net”命名空间下。如果客户端调用WebRequest.Create()方法，并传入“net.tcp://www.agiledon.com”值，则Create()方法就会对该Uri地址进行解析，获得完整的类型名为“System.Net.NettcpWebRequest”，然后，利用反射技术创建该对象。采用“惯例优于配置”的方式，可以极大地简化工厂方法的实现代码，抛弃了繁琐的设计理念，具有非常灵活的扩展性以及良好的代码可读性。或许，唯一的遗憾是由于反射技术带来的性能损耗。
利用抽象的方式封装变化，固然是应对需求变化的王道，但它也仅仅能解除调用者与被调用者之间的耦合关系。只要还涉及具体对象的创建，即使引入了创建型模式，例如Factory Method模式，具体工厂对象的创建依然是必不可少的。不要小看这一点点麻烦，需知“千里之堤，溃于蚁穴”，牵一发而动全身，小麻烦可能会酿成大灾难。对于那些业已被封装变化的对象，我们还应该学会利用诸如“依赖注入”、“表驱动法”等技术，彻底解除两者之间的耦合;至于选择何种技术，则需要根据具体的应用场景做出判断。当然，模块或对象解耦的重要前提，则源于封装变化，要求我们针对接口编程，而不是实现。这也是GOF提出的面向对象设计原则。
