（续上篇）
“到底如何去改良策略模式呢？”小菜恳切地问道。
“你仔细观察过没有，你的代码，不管是用工厂模式写的，还是用策略模式写的，那个分支的switch依然去不掉。原因在哪里？”大鸟反问道。
“因为程序里有下拉选择，用户是有选择的，那么程序就必须要根据用户的选择来决定实例化哪一个子类对象。无论是在客户端窗体类编程还是到工厂类里编程，这个switch总是少不掉的。问题主要出在这里。”小菜十分肯定的说。
“是呀，”大鸟道，“所以我们要考虑的就是可不可以不在程序里写明‘如果是打折就去实例化CashRebate类，如果是返利就去实例化CashReturn类’这样的语句，而是在当用户做了下拉选择后，再根据用户的选择去某个地方找应该要实例化的类是哪一个。这样，我们的switch就可以对它说再见了。”
“听不太懂哦，什么叫‘去某个地方找应该要实例化的类是哪一个’？’小菜糊涂地说。
“，我要说的就是一种编程方式：依赖注入（Dependency Injection），从字面上不太好理解，我们也不去管它。关键在于如何去用这种方法来解决我们的switch问题。本来依赖注入是需要专门的IoC容器提供，比如spring.net，显然当前这个程序不需要这么麻烦，你只需要再了解一个简单的.net技术‘反射’就可以了。”
“大鸟，你一下子说出又是‘依赖注入’又是‘反射’这些莫名其妙的名词，我有点晕哦！”小菜有些犯困，“我就想知道，如何向switch说bye-bye！至于那些什么概念我不想了解。”
“心急讨不了好媳妇！你急什么？”大鸟嘲笑道，“反射技术看起来很玄乎，其实实际用起来不算难。”
“请看下面的两个样例：
//实例化方法一 //原来我们把一个类实例化是这样的 Animal animal=new Cat(); //声明一个动物对象，名称叫animal，然后将animal实例化成猫类的对象 //实例化方法二 //我们还可以用反射的办法得到这个实例 using System.Reflection;//先引用System.Reflection //假设当前程序集是AnimalSystem，名称空间也是AnimalSystem Animal animal = (Animal)Assembly.Load("AnimalSystem").CreateInstance("AnimalSystem.Cat");