前言
在看了肥朝之前Dubbo原始碼解析系列的粉絲.出去面試一般都是上來一波操作猛如虎的原始碼分析,技驚四座!當然也有一些喜歡打我臉的粉絲做了如下反饋:
言歸正傳,在面試"造火箭"的過程中,最常問的又最有區分度的一些問題
-
你對XXX原始碼這麼熟悉,那有沒有遇到過什麼坑?面試官問我，使用Dubbo有沒有遇到一些坑？我笑了。
-
你看了這麼多原始碼,那請問學到了什麼?
坦白說,在面試官稍微一深入原理就喊疼,只能被迫換個姿勢繼續深入其他話題的情況下,一般是不太可能遇到這兩個問題的.但是如果你認真看過之前的原始碼解析和真實場景原始碼實戰系列,被問到這個兩個問題時又如何做到和肥朝一樣坐懷不亂?
本文並非要做出所謂的標準答案,畢竟每個人看問題角度不同,學到的自然不懂,本文主要希望通過拋磚引玉的方式,讓你在看原始碼時經過深度思考,而不是隻是為了面試裝裝逼.如果只是為了裝裝逼,那和每天喊著減肥,卻只是為了嚇一嚇身上的肉一樣,毫無意義!
原始碼中的分層結構
SpringMVC
我們先來看一下SpringMVC中HttpMessageConverter的分層結構設計,規範的命名讓我們很容易從單詞中就很容易猜出,這個類的作用是,將資料做相應轉化並響應回去.大白話就是,把你controller的實體類,轉換成相應的資料給前端.那我們來看一下,這個類,SpringMVC是怎麼對這個需求進行程式碼分層結構設計的
仔細分析我們不難發現,最外層的是響應格式
MappingJackson2HttpMessageConverter (json)
MappingJackson2XmlHttpMessageConverter (xml)
再往裡,就是序列化工具選擇
AbstractJackson2HttpMessageConverter (jackson)
ResourceRegionHttpMessageConverter
GsonHttpMessageConverter (gson)
再接著,就是公共的抽象類.
那麼關鍵問題來了,它為什麼這麼設計,以及這麼設計,會有什麼好處?
那我問你,假如你需要增加一種序列化方式,比如fastjson,你會怎麼做?
很明顯,照葫蘆畫瓢,你參考jackson和gson的做法都知道,是需要繼承AbstractGenericHttpMessageConverter,然後新建一個FastJsonHttpMessageConverter的類做額外的特殊處理啦.這就是大佬們常說的好的程式碼會說話.
另外他這麼分層,還有一個好處.你想一下,像這種把實體類轉換成相應資料的功能,如果要擴充,我們會擴充哪幾個方面?肥朝認為,無非是兩個方面,一個是響應的格式,比如JSON、XML、String.另一個是,序列化的工具,比如fastjson、jackson、gson.你再看一下這個分層,無論是改響應的格式和序列化工具都很輕鬆,維護性好很多.並且擴充後,單元測試也能細粒度測試擴充的功能,不至於出現程式碼深不可"測"
可見,在程式碼分層時,我們其實是可以從後續可能擴充性的這個角度來做分層
Dubbo
肥朝公眾號的粉絲大部分是看過Dubbo原始碼解析系列的,因此我們有必要來看看Dubbo裡面又是怎麼做的呢?
內容太多,我們可以拿Remoting(遠端通訊)模組來看看.他主要分Exchange(資訊交換層)、Transport(網路傳輸層)、Serialize(資料序列化層)這麼幾層.
Exchange(資訊交換層): 封裝請求響應模式.
Transport(網路傳輸層): 網路傳輸方式的統一介面
Serialize(資料序列化層): 資料的序列化
從剛才的原始碼經驗來看,我們想想,對於遠端通訊(Remoting),他為什麼要這麼分層?
對於遠端通訊這個需求,我們可能會有哪幾個方面的擴充需求?
-
請求響應模式(同步、非同步)
-
比如網路框架的選擇(Netty,Mina,JDK API)
-
比如序列化方式(Kryo,JSON,JDK序列化等)
可見,Dubbo在做程式碼分層時,和SpringMVC一樣,也是從後續可能擴充性的這個角度來做分層
寫在最後
當然不少同學遇到面試造出了火箭,順利入職後卻發現做的是擰螺絲的活!此時手中的大刀摁都摁不住!
但是其實技術是要服務於業務開發的,在業務開發中,需求頻繁改動是家常便飯.除了向肥朝借讀以下書籍之外
我們也可以把業務程式碼,按照我們從原始碼中學來的方式進行編碼,這樣才是真正碼出高效,每天早點下班,不至於出現公司沒給夠你泡妞的錢,還剝奪你泡妞的時間,最後搞壞了你泡妞的身體!
肥朝 是一個專注於 原理、原始碼、開發技巧的技術公眾號，號內原創專題式原始碼解析、真實場景原始碼原理實戰（重點）。掃描下面二維碼關注肥朝，讓本該造火箭的你，不再擰螺絲！