小菜编程成长记(八 反射——程序员的快乐!)
[2] 小菜编程成长记(八 反射——程序员的快乐!)
[3] 小菜编程成长记(八 反射——程序员的快乐!)
系列文章导航:
小菜编程成长记(九 会修电脑不会修收音机?——聊设计模式原则)
小菜编程成长记(十一 无熟人难办事?——聊设计模式迪米特法则)
小菜编程成长记(十三 设计模式不能戏说!设计模式怎就不能戏说?)
(续上篇)
“到底如何去改良策略模式呢?”小菜恳切地问道。
“你仔细观察过没有,你的代码,不管是用工厂模式写的,还是用策略模式写的,那个分支的switch依然去不掉。原因在哪里?”大鸟反问道。
“因为程序里有下拉选择,用户是有选择的,那么程序就必须要根据用户的选择来决定实例化哪一个子类对象。无论是在客户端窗体类编程还是到工厂类里编程,这个switch总是少不掉的。问题主要出在这里。”小菜十分肯定的说。
“是呀,”大鸟道,“所以我们要考虑的就是可不可以不在程序里写明‘如果是打折就去实例化CashRebate类,如果是返利就去实例化 CashReturn类’这样的语句,而是在当用户做了下拉选择后,再根据用户的选择去某个地方找应该要实例化的类是哪一个。这样,我们的switch就 可以对它说再见了。”
“听不太懂哦,什么叫‘去某个地方找应该要实例化的类是哪一个’?’小菜糊涂地说。
“,我要说的就是一种编程方式:依赖注入(Dependency
Injection),从字面上不太好理解,我们也不去管它。关键在于如何去用这种方法来解决我们的switch问题。本来依赖注入是需要专门的IoC容
器提供,比如spring.net,显然当前这个程序不需要这么麻烦,你只需要再了解一个简单的.net技术‘反射’就可以了。”
“大鸟,你一下子说出又是‘依赖注入’又是‘反射’这些莫名其妙的名词,我有点晕哦!”小菜有些犯困,“我就想知道,如何向switch说bye-bye!至于那些什么概念我不想了解。”
“心急讨不了好媳妇!你急什么?”大鸟嘲笑道,“反射技术看起来很玄乎,其实实际用起来不算难。”
“请看下面的两个样例:
Code
其中关键是
Assembly.Load("程序集名称").CreateInstance("名称空间.类名称")
那也就是说,我们可以在实例化的时候,再给计算机一个类的名称字符串,来让计算机知道应该实例化哪一个类。”大鸟讲解道。
“你的意思是,我之前写的‘cc.setBehavior(new CashNormal());’可以改写为‘cc.setBehavior((CashSuper)Assembly.Load("商场管理软 件").CreateInstance("商场管理软件.CashNormal")’,不过,这只不过是换了种写法而已,又有什么神奇之处呢?”小菜依然 迷茫。
“分析一下,原来new CashNormal()是什么?是否是写死在程序里的代码,你可以灵活更换吗?”大鸟问。
“不可以,那还换什么,写什么就是什么了呗。”
“那你说,在反射中的CreateInstance("商场管理软件.CashNormal"),可以灵活更换‘CashNormal’吗?”大鸟接着问。
“还不是一样,写死在代码…………等等,哦!!!我明白了。”小菜一下子顿悟过来,,兴奋起来。“因为这里是字符串,可以用变量来处理,也就可以根据需要更换。哦,My God!太妙了!”
“哈哈,博客园中的有篇博文《四大发明之活字印刷——面向对象思想的胜利》中曾经写过,‘体会到面向对象带来的好处,那种感觉应该就如同是一中国酒鬼第一次喝到了茅台,西洋酒鬼第一次喝到了XO一样,怎个爽字可形容呀。’,你有没有这种感觉了?”
“嗯,我一下子知道这里的差别主要在原来的实例化是写死在程序里的,而现在用了反射就可以利用字符串来实例化对象,而变量是可以更换的。”小菜说道。