此處記錄點零散的小idea,為了避免把csdn當微博,開一篇,都記在這里吧。
感覺服務注冊機制,貌似也是一種依賴注入。(雖然我還沒完全搞懂依賴注入),理由呢:你需要一個模塊的功能,該模塊作為一個服務注冊上,你就能用,沒注冊,你的服務請求失敗,這樣不會出現連build都不過的情況,也達到了解耦的目的,而依賴注入貌似也是幫你完成某個對象的裝配,我們可以通過控制依賴注入來靈活的配置裝配對象,這樣功能的變更不會影響到你的模塊,依賴注入配置下就好了,同樣目的是解耦。
依賴注入的優勢,有時構造一個對象時,很可能這個類的初始化依賴很多其他的類對象,這樣一個個都初始化好了,然后再初始化我們需要的類,導致關系復雜,其他不太關心的對象都要了解它的構造過程,而依賴注入可以解決這個問題,不關心具體的組裝流程。
“大多數面向對象編程語言,在調用一個類的時候,先要實例化這個類,生成一個對象。如果你在寫一個類,過程中要調用到很多其它類,甚至這里的其它類,也要“依賴”于更多其它的類,那么可以想象,你要進行多少次實例化。這就是“依賴”的意思。依賴注入,全稱是“依賴注入到容器”, 容器(IOC容器)是一個設計模式,它也是個對象,你把某個類(不管有多少依賴關系)放入這個容器中,可以“解析”出這個類的實例。所以依賴注入就是把有依賴關系的類放入容器(IOC容器)中,然后解析出這個類的實例。僅此而已。”
作者:唐思
鏈接:https://www.zhihu.com/question/32108444/answer/54773302
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。builder參數構建:初始化時有很多參數,都通過構造函數設置,有時發現某些參數不需要,也要傳遞,導致代碼寫了很長很多,很多參數只能設置是null,不想寫null,又要寫很多不同參數構造函數,所以通過builder更靈活。
淺談天貓tangram框架
天貓開源的tangram框架,十分適合電商平臺的商品展示,方便業務的運營,但是它不支持那種卡片內有click button的處理,一般都是一整張卡片一個處理,不適合一些功能性卡片的開發。不過目前沒看到有什么好的庫和框架,導致recyclerview寫的很煩,有個BRVAH(BaseRecyclerViewAdapterHelper)貌似可以簡化寫recyclerview的煩惱。不夠貌似不是很知名,不太敢用。吐槽一下,android app開發都發展的過氣了,很多很基礎的功能的庫竟然還這么不完善,一些邏輯的處理要寫的很復雜,層層嵌套的,套用調侃前端的一句話,要感謝這些app(前端)開發人員,在這么混亂的框架下,仍然寫出了這么多“優秀”的程序。我們寫代碼,究竟是在寫什么?
什么是代碼,什么是技術?其實編程只是一門工程,和科學不太搭邊,做科學研究的只是在利用編程手段完成一些計算處理。而大部分靠編程吃飯的人,都更關注工程方面,而工程方面,主要的關注點在于對業務的抽象能力,如果將復雜的業務抽象分類成一個個簡單的模型。這個應該是考察一個工程師最重要的能力,而其他領域知識,是”技“的范疇,是一個時間,經歷的積累過程。想不通android里面fragment竟然不能處理back pressed事件。
我是個很tmd能挑刺的人,對于android系統有些接口功能的設計,感到十分“惡心”,比如這個fragment不能處理back pressed事件,比如recyclerview竟然沒有官方上拉刷新,沒有一個好用的播放器控件(最近封裝mediaPlayer都要吐了),很多人可能很坦然的接受,對于這個問題,我的觀點:如果在前幾年這些都能夠接受,而現在android開發已經快”窮途末路“了,竟然很多東西都如此不完善,我并不是存粹的拿來主義,什么都別人做好拿來用,而是希望有良好的分工,基礎功能分層,不涉及定制化很多,性能要求很高的基礎組件盡量完善,讓不同的開發人員處理各自領域的事情。而不是很多東西都從玩泥巴開始。另外對于很多開發者認為研究”底層“原理才牛逼,動不動就分析底層源碼的行為,面試時更是動不動喜歡問實現機制的行為,十分不贊同,底層軟件就真的高深嗎,軟件是一個把復雜問題抽象成簡單問題的過程,代碼是寫的簡單才牛逼,而不是復雜。不論上層業務還是底層基礎軟件都是考驗抽象,分解,歸納的架構能力。本人之前從事”內核“”驅動“開發,經常遇到很多初生牛犢動不動就想寫個操作系統什么的?我一直的觀點就是:這個世界上不需要那么多操作系統。如果沒有革命性的技術變革,你不過就是copy一份linux,縮小版的。站在巨人的肩膀上構建你的代碼,當巨人病了的時候,再去研究巨人。我看過太多自己的業務代碼寫的一團糟,模塊分離不清,各種耦合,重復代碼,卻整天想著研究底層原理的開發者,先寫好自己手頭的代碼,多看看設計模式吧。