看過不少資料，凡是談到介面，基本上都會提到依賴注入，組合程式設計，模組解耦這三個概念。這些概念在《軟體框架設計的藝術》這本書裡都有提到。這本書的前言裡有一段話是說，之所以稱之為藝術，是因為很難用語言去描述它，有些人可能已經在使用了，但是卻說不出其中為啥好的道理來。今天在試圖優化框架編譯檔案大小的過程中，對介面的使用又有些體會，記錄一下。

先說關於包結構定義的體會。

之前移植了Flex的繪圖元素模組。今天看了下庫編譯大小，275K。我想測試了下，移除掉繪圖元素模組會是多少。當初就是想要可以隨時刪掉這個模組。所以就把所有繪圖元素相關的類都放在同一個包裡。我一刪除，卻發現報錯了。有幾個components包下面的元件引用了繪圖元素裡的幾個介面。我回頭去看Flex裡這幾個介面原始的包結構。它們都是被放到了框架的core包下面的。瞬間明白了。我之前一直認為core這個包是跟它的名字一樣是放最核心的類和介面的。其實不然。有很多類比core包裡的核心多了，比如LayoutManager，所有的UI元件都基於這個類的自動佈局機制執行的。但是它沒在core包裡。重新看了一遍core包的內容。發現必須放在這裡面的類和介面都有一個共同點：它們有可能被很多模組同時引用。所以跟貼切的理解應該是這樣：框架裡不管怎麼設計，總是會有存在模組依賴的。而core包裡就應該放置這些無法解耦被公共依賴的部分。然後其他模組都引用core包的內容，而各自之間就能保持獨立了。這樣分的包結構，物理上隔離了各個模組，只要保證core包的內容不變，其他模組都應該是可以直接刪除而不影響另外一個模組的編譯的。也就不存在我現在遇到的報錯的這個問題了。

再回到介面使用上

再看一遍core包裡的內容，會發現還有一個共同點：絕大部分檔案都是介面和常量定義。只有一個元件UIComponent，因為它是所有UI的基類。根據前面的結論，我們不難得出一個結論：框架的公共依賴部分都應該是介面。也就是說，各個模組之間並沒有直接的引用，而都是通過介面間接引用的。沒有直接引用帶來的好處是在編譯階段體現出來的。比如一個有10個模組的框架，在專案中，我只用到了其中的1個模組，但是由於模組之間存在類的直接引用，而不是介面。因為類的引用都是跟蜘蛛網一樣不斷擴充套件的，類引用的任何類都會被編譯。最終編譯進專案的框架程式碼就可能會同時有10個模組的程式碼！這樣顯然不是我們願意看到的。而如果是用介面來隔離類的直接引用。不管使用的是哪個模組，最終都會只編譯對應的模組，附加core包裡的幾個介面進去。僅此而已，顯然更加經濟。這樣，其實我如果做好了框架的解耦，根本都不需要去考慮移除掉繪圖模組來達到精簡的目的。專案中如果不需要，不使用即可，不會增加最終編譯的檔案大小。

所以，如果使用對了介面，可以很好地解決耦合問題。但是以上的方式不是萬能的，只能解決一部分，對於還是不能有效解決耦合的部分，就要試試依賴注入了。