本文目錄一覽：
IO流中的設計模式
1.IO中用到的適配器模式
在IO中，如將字元串數據轉變成位元組數據保存到文件中，將位元組數據轉變成流數據等都用到了適配器模式，下面以InputStreamReader和OutputStreamWriter類為例介紹適配器模式。
InputStreamReader和OutputStreamWriter類分別繼承了Reader和Writer介面，但要創建它們必須在構造函數中傳入一個InputStream和OutputStream的實例，InputStreamReader和OutputStreamWriter的作用也就是將InputStream和OutputStream適配到Reader和Writer。
InputStreamReader實現了Reader介面，並且持有了InputStream的引用，這是通過StreamDecoder類間接持有的，因為byte到char要經過編碼。
這裡，適配器就是InputStreamReader類，而源角色就是InputStream代表的實例對象，目標介面就是Reader類，OutputStreamWriter類也是類似的方式。
在IO中類似的還有，如StringReader將一個String類適配到Reader介面，ByteArrayInputStream適配器將byte數組適配到InputStream流處理介面。
2.IO中用到的裝飾模式
裝飾模式就是對一個類進行裝飾，增強其方法行為，在裝飾模式中，作為原來的這個類使用者還不應該感受到裝飾前與裝飾後有什麼不同，否則就破壞了原有類的結構了，所以裝飾器模式要做到對被裝飾類的使用者透明，這是對裝飾器模式的一個要求。總之裝飾器設計模式就是對於原有功能的擴展
在IO中有許多不同的功能組合情況，這些不同的功能組合都是使用裝飾器模式實現的，下面以FilterInputStream為例介紹裝飾器模式的使用。
InputStream類就是以抽象組件存在的，而FileInputStream就是具體組件，它實現了抽象組件的所有介面，FilterInputStream類就是裝飾角色，它實現了InputStream類的所有介面，並持有InputStream的對象實例的引用，BufferedInputStream是具體的裝飾器實現者，這個裝飾器類的作用就是使得InputStream讀取的數據保存在內存中，而提高讀取的性能。類似的還有LineNumberInputStream類，它的作用是提高按行讀取數據的功能。
總結
這兩種設計模式看起來都是起到包裝一個類或對象的作用，但是使用它 們的目的卻不盡相同。適配器模式主要在於將一個介面轉變成另一個介面，它的目的是通過改變介面來達到重複使用的目的；而裝飾器模式不是要改變被裝飾對象的介面，而是保持原有的介面，但是增強原有對象的功能，或改變原有對象的方法而提高性能。
補充：高性能的IO體系。
首先得明白什麼是同步，非同步，阻塞，非阻塞.
1,同步和非同步是針對應用程序和內核的交互而言的
2,阻塞和非阻塞是針對於進程在訪問數據的時候，根據IO操作的就緒狀態來採取的不同方式
總結一句簡短的話，同步和非同步是目的，阻塞和非阻塞是實現方式。
名詞解釋
同步 指的是用戶進程觸發IO操作並等待或者輪詢的去查看IO操作是否就緒 自己上街買衣服，自己親自干這件事，別的事幹不了。
軟體開發中的裝飾器模式是什麼呢？
裝飾器模式就是動態地給一個對象添加一些額外的職責。就增加功能來說，裝飾器模式相比生成子類更為靈活。
1.裝飾器模式允許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬於結構性模式，它是作為現有的類的一個包裝。
2.這種模式創建了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。
3.我們通過下面的實例來演示裝飾器模式的用法。其中，我們將把一個形狀裝飾上不同的顏色，同時又不改變形狀類。
什麼是裝飾器模式
裝飾器模式是允許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬於結構型模式，它是作為現有的類的一個包裝。通俗的來講，就是一個對象嵌入到另一個對象中去，實際上相當於這個對象被另一個對象包裝起來，形成一條包裝鏈。
主要是解決為了擴展一個類經常使用繼承方式實現，由於繼承為類引入靜態特徵，並且隨著擴展功能的增多，子類會很膨脹。優點是，裝飾類和被裝飾類可以獨立發展，不會相互耦合，裝飾模式是繼承的一個替代模式，裝飾模式可以動態擴展一個實現類的功能。
應用場景：（a）在不影響其他對象的情況下，以動態、透明的方式給單個對象添加職責。 (b) 需要動態地給一個對象增加功能，這些功能也可以動態地被撤銷。 當不能採用繼承的方式對系統進行擴充或者採用繼承不利於系統擴展和維護時。
在裝飾器模式中的角色有：
抽象構件(Component)角色：給出一個抽象介面，已規範準備接收附加責任的對象。具體構件(ConcreteComponent)角色：定義一個將要接收附加責任的類。裝飾(Decorator)角色：持有一個構件(Component)對象的實例，並定義一個與抽象構件介面一致的介面。具體裝飾(ConcreteDecorator)角色：負責給構件對象「貼上」附加的責任。
設計模式|菜鳥教程 – C3 結構型模式
適配器模式：SD讀卡器
橋接模式：抽象是抽象，具體是具體，隔離開來
過濾器模式：結果是一個list，用不同的標準類去過濾
組合模式：樹
裝飾器模式：實現同一套介面，但是增加功能
外觀模式：隱藏結構的複雜性，比如提供一個api介面，每個api調用的模塊細節隱藏
享元模式：
代理模式：實現同一套介面，但是功能不變，只是加一下控制
創建一個介面類，集成被擴展的類；
是作為兩個不兼容的介面之間的橋樑。這種類型的設計模式屬於結構型模式，它結合了兩個獨立介面的功能。
舉個真實的例子SD讀卡器，讀卡器是作為內存卡和筆記本之間的適配器。您將內存卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過筆記本來讀取內存卡。
我們通過下面的實例來演示適配器模式的使用。其中，音頻播放器設備只能播放 mp3 文件，通過使用一個更高級的音頻播放器來播放 vlc 和 mp4 文件。
應用實例：
比如繪製四種車，每種車有3種啟動方式，將抽象和實現分離，解決多次繼承的問題。
不必要的繼承導致類爆炸；
在一個抽象類裡面聚合其他的抽象類（比多繼承好）
使用場景：
過濾器模式（Filter Pattern）或標準模式（Criteria Pattern）是一種設計模式，這種模式允許開發人員使用不同的標準來過濾一組對象，通過邏輯運算以解耦的方式把它們連接起來。
即聲明一種檢測標準類，如下：
通過實現這個介面來選出不同的對象。
其實就是樹的架構，每個節點都相同
應用實例：
動態地給一個對象添加一些額外的職責。就增加功能來說，裝飾器模式相比生成子類更為靈活。
類圖：
以下情況可以使用裝飾器模式：
隱藏系統的複雜性，並向客戶端提供了一個客戶端可以訪問系統的介面。這種類型的設計模式屬於結構型模式，它向現有的系統添加一個介面，來隱藏系統的複雜性。
享元模式嘗試重用現有的同類對象，如果未找到匹配的對象，則創建新對象。
跟單例模式差不多，可以稱之為多例模式：
核心使用一個hashmap存儲一個之前用過的對象，如果有了就不用創建新的了
何時使用：
應用實例：
一個類代表另一個類的功能。
主要解決：在直接訪問對象時帶來的問題，比如說：要訪問的對象在遠程的機器上。在面向對象系統中，有些對象由於某些原因（比如對象創建開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問），直接訪問會給使用者或者系統結構帶來很多麻煩，我們可以在訪問此對象時加上一個對此對象的訪問層。
例子：
注意事項：
Kubectl源碼閱讀
本章的任務主線任務如下
其實kubectl的每個子命令流程大體分為三步,
首先以下面的命令作為起始任務，看看kubectl的代碼結構
kubernetes的所有組件入口函數幾乎都是一致的，使用的命令行解析庫是cobra
為什麼不直接用標準庫的flag呢？因為標準庫的flag庫與linux下的POSIX命令行參數標準不兼容，比如linux下的命令行 -a -b可以連起來寫成-ab, 而golang官方庫的flag不支持。
在深入get.NewCmdGet(“kubectl”, f, ioStreams)之前，首先看看委託者模式
輸出如下:
總的來書，具體的實現由Delegate實現，上層就是一層層的往下委託, 而kubectl中的f := cmdutil.NewFactory(matchVersionKubeConfigFlags)就是如此。
以ToRESTConfig方法為例,委託調用鏈如下
委託模式使得我們可以用聚合來替代繼承，它還使我們可以模擬mixin
每個cobra.Command的創建其實差不多
在深入請求的邏輯之前先看看代碼中用到的設計模式，其實還有一個裝飾器模式，但其實就是在原函數的基礎上包裝一層，就不說了。
訪問者模式的好處在於將熟悉的配置抽象成方法，可以隱藏一些複雜的細節，以及控制內部屬性
輸出如下
訪問者模式的好處在於定義統一的介面讓外部與內部交流，解耦數據與數據處理邏輯。
從上文知道，result對象最終在Do方法中創建，所以看下它對應的實現。
那麼從外層到內層的調用鏈如下:
構造對應的result對象
這個result對象的構造過程比較複雜，我也沒完全看懂，等我看懂了在來寫吧。
那麼繼續看看數據在哪裡出發吧。
未完待續。。。。
原創文章，作者：FBGHM，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/313722.html
微信掃一掃 
支付寶掃一掃 