public class quicksort:isort
{
private icompare m_compare;
public quicksort(icompare compare)
{
m_compare= compare;
}
public void sort(ref object[] besorted)
{
//实现略
for (int i = 0; i ＜ besorted.length - 1; i++)
{
if (m_compare.compare(besorted[i],besorted[i+1))
{
//略；
}
}
//实现略
}
}
最后的类图如下：
通过对比较策略的封装，以应对它的变化，显然是stategy模式的设计。事实上，这里的排序算法也可能是变化的，例如实现二叉树排序。由于我们已经引入了“面向接口编程”的思想，我们完全可以轻易的添加一个新的类binarytreesort，来实现isort接口。对于调用方而言，isort接口的实现，同样是一个strategy模式。此时的类结构，完全是一个对扩展开发的状态，它完全能够适应类库调用者新需求的变化。
再以petshop为例，在这个项目中涉及到订单的管理，例如插入订单。考虑到访问量的关系，petshop为订单管理提供了同步和异步的方式。显然，在实际应用中只能使用这两种方式的其中一种，并由具体的应用环境所决定。那么为了应对这样一种可能会很频繁的变化，我们仍然需要利用“封装变化”的原理，建立抽象级别的对象，也就是iorderstrategy接口：
public interface iorderstrategy
{
void insert(petshop.model.orderinfo order);
}
然后定义两个类ordersynchronous和orderasynchronous。类结构如下：
在petshop中，由于用户随时都可能会改变插入订单的策略，因此对于业务层的订单领域对象而言，不能与具体的订单策略对象产生耦合关系。也就是说，在领域对象order类中，不能new一个具体的订单策略对象，如下面的代码：
iorderstrategy orderinsertstrategy = new ordersynchronous();
在martin fowler的文章《ioc容器和dependency injection模式》中，提出了解决这类问题的办法，他称之为依赖注入。不过由于petshop并没有使用诸如sping.net等ioc容器，因此解决依赖问题，通常是利用配置文件结合反射来完成的。在领域对象order类中，是这样实现的：
public class order
{
private static readonly iorderstategy orderinsertstrategy = loadinsertstrategy();
private static iorderstrategy loadinsertstrategy()
{
// look up which strategy to use from config file
string path = configurationmanager.appsettings["orderstrategyassembly"];
string classname = configurationmanager.appsettings["orderstrategyclass"];
// load the appropriate assembly and class
return (iorderstrategy)assembly.load(path).createinstance(classname);
}
}
在配置文件web.config中，配置如下的section：
＜add key="orderstrategyassembly" value="petshop.bll"/＞
＜add key="orderstrategyclass" value="petshop.bll.ordersynchronous"/＞
这其实是一种折中的service locator模式。将定位并创建依赖对象的逻辑直接放到对象中，在petshop的例子中，不失为一种好方法。毕竟在这个例子中，需要依赖注入的对象并不太多。但我们也可以认为是一种无奈的妥协的办法，一旦这种依赖注入的逻辑增多，为给程序者带来一定的麻烦，这时就需要一个专门的轻量级ioc容器了。
写到这里，似乎已经脱离了“封装变化”的主题。但事实上我们需要明白，利用抽象的方式封装变化，固然是应对需求变化的王道，但它也仅仅能解除调用者与被调用者相对的耦合关系，只要还涉及到具体对象的创建，即使引入了工厂模式，但具体的工厂对象的创建仍然是必不可少的。那么，对于这样一些业已被封装变化的对象，我们还应该充分利用“依赖注入”的方式来彻底解除两者之间的耦合。
