上次隨便一吐，發(fā)現(xiàn)挺多共鳴的，好吧，今天我來吐一吐亂用注入。
注入是個很裝逼的詞語，java對這個詞解釋的神鬼都怕，高級裝逼直的人稱ioc,di什么的，入行淺的人看著高深，其實(shí)就是給對象屬性賦個值而已。學(xué)術(shù)界的老師教授等人就喜歡搞這種東西，用十個你沒聽過的詞來解釋一個你沒聽過的詞，說得太明白怕你們知道他不懂怎么辦。好像吐錯方向了，下面直接說正題吧。
舉個例子，A界面打開B界面，B界面點(diǎn)擊個按鈕后需要A界面做些反應(yīng)。有些人給出下面這個方案。A構(gòu)造出B的時候把A的一個函數(shù)傳給B，B操作完回調(diào)A。我先不否定，如果是做彈窗回調(diào)，這樣做是沒問題的。下面我再說一個復(fù)雜一些的，A界面打開B界面打開C界面，然后函數(shù)從A傳到了C，不僅如此，D需要用到C，也傳參到C。那么問題來了，你寫代碼的時候，發(fā)現(xiàn)C對象里面有一個函數(shù)變量，你要找出這個函數(shù)是從哪里注入(賦值)進(jìn)來的。全局查到BD都有可能會注入，糾結(jié)了吧，還得先把BD給讀一下看能不能改。再說一個更坑爹的，你的需求變了，你需要修改C，好吧，可以開噴了。我只想改C,結(jié)果我不得不把AB和C都讀一下看能不能改，或者干脆ABCD都改了。如果是把一個接口從A傳到C還算是幸運(yùn)的，起碼知道接口里面有什么，但是有很多過份的做法是把一個反射函數(shù)傳他個五六七八次。這時候策劃來一需求要改這五六七八次的其中一次，這種技術(shù)員就開始罵策劃了。
可能上面說例子有點(diǎn)腦亂，我再說一個寫前端的人肯定會碰到過的，父類界面A傳一個參數(shù)給子界面B，子界面B又傳給子界面C。最下層的C界面操作完了,父類A界面發(fā)生改變。一種很糟糕的做法是把A的函數(shù)傳到C，給C調(diào)用。當(dāng)別人讀碼的時候，找這個函數(shù)從哪里傳來的，要把這一條長長傳遞鏈全部往上找一遍，這條鏈只要有一個需求改了，修改就痛苦了。然后又有人給出了下面這個方案。界面A設(shè)成單例，C調(diào)用A單例執(zhí)行他的方法，這個方案是解決了可讀性，但是帶來另外的問題，所有界面都搞成單例就意為著無法繼承復(fù)蓋，無法用上篇文章我說的解耦方法，而且界面A不能多開，還有個問題就是所有界面全占著內(nèi)存無法釋放。
好吧，噴歸噴，下面說說解決方案。有經(jīng)驗(yàn)的人早就想到了，那就是用事件。子界面發(fā)個事件給A接收就行了，不管A到Z經(jīng)過了次傳遞，Z要讓A反應(yīng)只有一級。有人會說，Z想要用A的數(shù)據(jù)怎么辦？解決方案是把數(shù)據(jù)做成單例，不管A里面有多少子項(xiàng)，各子項(xiàng)都是自己從數(shù)據(jù)單例里拿數(shù)據(jù)自己解析自己，就算一個界面的子項(xiàng)有幾個人寫，這幾個人寫的東西也不需要修改別人的代碼來完成自己的邏輯（除了入口）,MVC解耦就是這個思路。當(dāng)然特例也是有的，例如列表父項(xiàng)要讓子項(xiàng)的位置變化，什么時候碰到讓我抓狂受不了的事件亂用再吐吧。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊(duì)列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實(shí)現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學(xué)習(xí)是年輕人改變自己的最好方式