【转载】浅谈 flash 中的设计模式：IoC

模式都是方法论，用于解决特定问题。产品开发过程中肯定遇到这样的问题：需求提过来，我开发；开发完毕之后需求人不满意，又提了新的需求，我又开发；完了还是不满意，需求再次被修改；这次提交后告诉我有些功能要拿掉；拿掉之后又告诉我，领导觉得那个功能挺好，还是加上来吧……于是我怒了，整了一份xml文档作为配置文件丢过去：功能如下，你丫自己装配——这，就叫IoC模式。

IoC全称Inversion of Control，即控制反转，也就是把对程序的控制移至程序之外，交由用户来控制。对于上面的这个例子，就是：作为开发者的我，理应控制程序所应实现的功能和方法，但由于需求的不可预期，我把对程序的控制权交给用户本人，由他们来选择装配，以实现最大的灵活性。IoC最好的例子应该就是java里面的spring了。IoC框架从xml中读取配置，在java里面利用反射的方法来实例化对象，再按照xml里规定的交互手段连接各个实例，就实现了控制反转。

这个模式的优势很明显，就是灵活，因为借助外力来反转控制，所以给程序轻松解耦，使得各个模块各干各的，彼此的依赖性降到最低。而缺点也很明显，增加开发工程量，程序员不得不将所有可能的需求都涵盖起来；控制反转所需的代价不小，性能的损失无法忽略。那么，什么时候使用它好呢？自然是对需求的预期不明确，程序很庞大而用户的覆盖面很广，所以为了照顾各种用户独特的需求必然要用一些手段来针对性的控制程序；还有就是，需要二次开发/加工的时候。

比如这次做3d产品展示，因为最终需求相对比较复杂，构成的功能模块很多，有些彼此独立，有些又交叉依赖；最终产品的维护和上线很可能不是我来做，所以就需要采用一种成熟的方法将这些需求细分。于是我想起来早先读到的IoC模式，继而寻求这种理论的指导，最终成功——这也验证了我之前对模式的描述：模式不是要学会弄透的，而是要程序员了解熟悉，当碰到问题的时候知道寻求怎样的解决。

不过可惜的是，flash（或称as3）无法完整支撑这个模式，因为编译的时候，没有明确声明的类不会被编译到swf中去，所以用反射的方法实例化行不通——当然我并没有使用成型的IoC框架，因为太复杂，所以这个说法未必准确——这样我就面临两个选择：第一，使用文档类的方式，将每个部件都发布成swf文件，然后通过运行时加载的方式来使用他们；第二，使用if else、switch case等语句来写死实例化内容。经过左右权衡之后我选择了第二种方式，因为短期内我的模块不会太多，功能会比较集中，写死不会太影响灵活性；其次，太多swf文件的部署非常困难，尤其是非本人部署的情况下，这点我深有体会。

flash里面无法执行IoC，但我们可以吸取其精神、精髓，运用到生产当中，解决问题。框架搭好之后，3d研究继续，互动的一章马上推出。

PS：上面对于模式和框架的理解均来自于我本人，可能和网上能查到的其他资料不符，也可能不够全面仔细准确，个人觉得领会精神无招胜有招最好，咔咔，望大家见谅。