學習自

https://www.jianshu.com/p/9c646002e2f7

這是一種好架構嗎？

有人認為，很好了。我第一眼看過去，也是很不錯了。因為這就是我的架構。專案會分成若干module。

其實不太好。

原因在於，耦合，你中有我，我中有你。為什麼這麼說呢？我是這麼寫的，比如A業務包，我會開放一定的API，然後也會開放一定的介面，我碰到寫不下去的功能了，有些東西不屬於我模組負責的，我直接扔個接口出來。別人去實現。其實這樣存在的弊端是，我A業務包的內部會包含實現者的引用。一個倒還好，可以接受，多了，這耦合還是不低。

所以這張圖變一變

看似沒什麼不同。其實我們是把所有的“介面”扔給了路由，讓他去統一管理了。

以前我是

private Action action=..;

public interface Action {

...

}

現在need("pay")，我就能呼叫支付功能了，相當於從顯示，變為了隱式。

但是我還看過美團貓眼，他是這樣解耦的：

它主要側重模組接入。裡面的下拉重新整理樣式、網路等庫，都也寫成need("功能")的形式，但是他不交給路由去統一配置，他為這個模組專門寫一個文字，所以主app想接入，寫個文字進來就好了。這樣我覺得也很好。

所以功能從介面.方法->need（“功能”），從顯示到隱式是我們必須要做的。但是這些所有的功能是否要由路由統一管理或者是一個模組一個文字，還需要見仁見智。我個人認為可以進行一個路由的配置（而且路由最好寫成restful的規範，比如功能/ 網路，頁面/商城主頁這樣的），再把路由註解內的東西寫成文字，似乎是一箇中和、上佳的選擇。

我對架構的理解：

沒有想象的那麼恐怖。其實就是程式碼不同位置的擺放。我們剛起步的時候，是一個Activity中的業務，UI流水賬下來的，後來慢慢地學會了用MVP，解耦了UI和資料；最後發展出代價更小，解耦程度更高的架構。其實只要架構好了，哪怕模組區域性亂一點，也是能寫下去的。如果沒有架構，專案規模又膨脹了，這個時候專案就做不下去了。

還有一個理解就是，不僅要注重全域性的架構，模組內部、區域性的程式碼也要注重架構。架構並不是一個巨集觀的名詞，只是換了一個地方放程式碼，讓你更容易找到、分類而已。