【IT168 专稿】一个外部具体对象的引入，必然会给一个模块带来与外部模块之间的依赖。而具体对象的创建始终是我们无法规避的。即使我们可以利用设计模式的工厂方法模式或抽象工厂封装具体对象创建的逻辑，但却又再次引入了具体工厂对象的创建依赖。虽然在设计上有所改进，但没有彻底解除具体依赖，仍让我心有戚戚焉。
以一个电子商务网站的设计为例。在该项目中要求对客户的订单进行管理，例如插入订单。考虑到访问量的关系，系统为订单管理提供了同步和异步的方式。显然，在实际应用中，我们需要根据具体的应用环境，决定使用这两种方式的其中一种。由于变化非常频繁，因而我们采取了“封装变化”的设计思想。譬如，考虑应用Strategy模式，因为插入订单的行为，实则就是一种插入订单的策略。我们可以为此策略建立抽象对象，如IOrderStrategy接口。
{
void Insert(OrderInfo order);
}
然后分别定义两个类OrderSynchronous和OrderAsynchronous实现IOrderStrategy接口。类结构如图1所示。
图1 订单策略的设计
当领域对象Order类需要插入订单时，将根据IOrderStrategy接口的运行期类型，执行相关的订单插入策略，如下代码所示。
{
private IOrderStrategy m_orderStrategy;
public Order(IOrderStrategy orderStrategy)
{
m_orderStrategy = orderStrategy;
}
public void Insert(OrderInfo order)
{
m_orderStrategy.Insert(order);
}
}
由于用户随时都可能会改变插入订单的策略，因此对于业务层的订单领域对象而言，绝不能与具体的订单策略对象产生耦合关系。也就是说，在领域对象Order类中，不能new一个具体的订单策略对象，如下面的代码：
虽然在前面的实现中，我们通过领域对象的构造函数传递了IOrderStrategy接口对象。但这样的实现仅仅是将具体订单策略对象的创建推迟到了领域对象的调用者那里而已，调用者无法避免具体订单策略对象的创建。显然，这是一种“治标不治本”的做法。我们当然也期望能够有一种理想的状态，就是具体对象的创建永远都不要在代码中出现。事实上，模块与模块间之所以产生依赖关系，正是因为有具体对象的存在。一旦在一个模块中创建了另一个模块中的具体对象，依赖就产生了。现在，我们的目的就是要将这些依赖消除。
