吐嘈一下乱用注入

上次随便一吐，发现挺多共鸣的，好吧，今天我来吐一吐乱用注入。

注入是个很装逼的词语，java对这个词解释的神鬼都怕，高级装逼直的人称ioc,di什么的，入行浅的人看着高深，其实就是给对象属性赋个值而已。学术界的老师教授等人就喜欢搞这种东西，用十个你没听过的词来解释一个你没听过的词，说得太明白怕你们知道他不懂怎么办。好像吐错方向了，下面直接说正题吧。

举个例子，A界面打开B界面，B界面点击个按钮后需要A界面做些反应。有些人给出下面这个方案。A构造出B的时候把A的一个函数传给B，B操作完回调A。我先不否定，如果是做弹窗回调，这样做是没问题的。

下面我再说一个复杂一些的，A界面打开B界面打开C界面，然后函数从A传到了C，不仅如此，D需要用到C，也传反射函数到C。那么问题来了，你写代码的时候，发现C对象里面有一个函数变量，你要找出这个函数是从哪里注入(赋值)进来的。全局查到BD都有可能会注入，纠结了吧，还得先把BD给读一下看能不能改。

再说一个更坑爹的，你的需求变了，你需要修改C，好吧，可以开喷了。我只想改C,结果我不得不把AB和C都读一下看能不能改。如果是把一个接口从A传到C还算是幸运的，起码知道接口里面有什么，但是有很多过份的做法是把一个反射函数传他个五六七八次。这时候策划来一需求要改这五六七八次的其中一次，这种技术员就开始骂策划了。

可能上面说例子有点脑乱，我再说一个写前端的人肯定会碰到过的，父类界面A传一个参数给子界面B，子界面B又传给子界面C。最下层的C界面操作完了,父类A界面发生改变。一种很糟糕的做法是把A的函数传到C，给C调用。当别人读码的时候，找这个函数从哪里传来的，要把这一条长长传递链全部往上找一遍，这条链只要有一个需求改了，修改就痛苦了。然后又有人给出了下面这个方案。界面A设成单例，C调用A单例执行他的方法，这个方案是解决了可读性，但是带来另外的问题，所有界面都搞成单例就意为着无法继承复盖，无法用上篇文章我说的解耦方法，而且界面A不能多开，还有个问题就是所有界面全占着内存无法释放。

好吧，喷归喷，下面说说解决方案。有经验的人早就想到了，那就是用事件。子界面发个事件给A接收就行了，不管A到Z经过了次传递，Z要让A反应只有一级。有人会说，Z想要用A的数据怎么办？解决方案是把数据做成单例，不管A里面有多少子项，各子项都是自己从数据单例里拿数据自己解析自己，就算一个界面的子项有几个人写，这几个人写的东西也不需要修改别人的代码来完成自己的逻辑（除了入口）,MVC解耦就是这个思路。当然特例也是有的，例如列表父项要让子项的位置变化，什么时候碰到让我抓狂受不了的事件乱用再吐吧。

 

下面说些复杂的，因为数据是从服务端过来，或者从数据库过来，并不会像界面那样需要继承，也不会像界面那些占用这么多内存。所以数据做成单例也不会有什么性能问题。有人说用了设计模式会浪费性能，也不知道这些没经验人的从哪来的这个结论。不用模式乱传参,传他五六七八次然后回调，跟监听者模式发一次事件相比，性能谁好，一目了然。有人说用模式会多写很多代码，做前端的，不管你什么项目都有界面，有数据。不用模式的其实就是把数据和界面写到一个类，用模式就是分开两个类来写，代码量有变多吗？参数一级级传递和只用一个事件相比，哪个代码量多？只是乱用才会多废代码吧。

曾带过的小弟读乱用模式的代码说，看不懂，但是感觉好高深……其实不用自卑，看不懂的代码不是读的人的问题，是写的人有问题。我曾拿一套很有经验的代码给小弟读，小弟说，就这样啊，这么简单粗暴。自己也是从新手过来的。对这种胡乱崇拜有说不出的味道。