在看了肥朝以前Dubbo源碼解析系列的粉絲.出去面試通常都是上來一波操做猛如虎的源碼分析,技驚四座
!固然也有一些喜歡打我臉
的粉絲作了以下反饋:前端
言歸正傳,在面試"造火箭"的過程當中,最常問的又最有區分度的一些問題面試
你對XXX源碼這麼熟悉,那有沒有遇到過什麼坑?面試官問我,使用Dubbo有沒有遇到一些坑?我笑了。json
你看了這麼多源碼,那請問學到了什麼?網絡
坦白說,在面試官稍微一深刻原理就喊疼,只能被迫換個姿式繼續深刻其餘話題的狀況下,通常是不太可能遇到這兩個問題的.可是若是你認真看過以前的源碼解析和真實
場景源碼實戰系列,被問到這個兩個問題時又如何作到和肥朝同樣坐懷不亂
?app
本文並不是要作出所謂的標準答案,畢竟每一個人看問題角度不一樣,學到的天然不懂,本文主要但願經過拋磚引玉的方式,讓你在看源碼時通過深度思考
,而不是隻是爲了面試裝裝逼.若是隻是爲了裝裝逼,那和天天喊着減肥,卻只是爲了嚇一嚇身上的肉
同樣,毫無心義!框架
咱們先來看一下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裏面又是怎麼作的呢?
內容太多,咱們能夠拿Remoting(遠程通信)模塊
來看看.他主要分Exchange(信息交換層)
、Transport(網絡傳輸層)
、Serialize(數據序列化層)
這麼幾層.
Exchange(信息交換層): 封裝請求響應模式.
Transport(網絡傳輸層): 網絡傳輸方式的統一接口
Serialize(數據序列化層): 數據的序列化
從剛纔的源碼經驗來看,咱們想一想,對於遠程通信(Remoting)
,他爲何要這麼分層?
對於遠程通信這個需求,咱們可能會有哪幾個方面的拓展需求?
請求響應模式(同步、異步)
好比網絡框架的選擇(Netty,Mina,JDK API)
好比序列化方式(Kryo,JSON,JDK序列化等)
可見,Dubbo在作代碼分層時,和SpringMVC同樣,也是從後續可能拓展性
的這個角度來作分層。
固然很多同窗遇到面試造出了火箭
,順利入職後卻發現作的是擰螺絲的活!此時手中的大刀摁都摁不住!
可是其實技術是要服務於業務開發的,在業務開發中,需求頻繁改動是屢見不鮮.除了向肥朝借讀如下書籍以外
咱們也能夠把業務代碼,按照咱們從源碼中學來的方式進行編碼,這樣纔是真正碼出高效,天天早點下班,不至於出現公司沒給夠你泡妞的錢,還剝奪你泡妞的時間,最後搞壞了你泡妞的身體!
肥朝 是一個專一於 原理、源碼、開發技巧的技術公衆號,號內原創專題式源碼解析、真實場景源碼原理實戰(重點)。掃描下面二維碼關注肥朝,讓本該造火箭的你,再也不擰螺絲!