在前面的幾天中我們說了以下幾個設計原則 :

• Day-02: 設計原則 SOLID — SRP
• Day-03 : 設計原則之 SOLID — ISP、DIP
• Day-04: 設計原則 SOLID — OCP、LSP

然後接下來是耦合性三原則 :

• Day-05: 耦合性三大原則 ADP、SDP、SAP

然後是聚合性三原則 :

• Day 06 : 設計原則之聚合性 ( Cohesion ) 三大原則 — REP、CCP、CRP

接下來這一些來整理他們的關連性與自已一些的看法。

SOLID 的關係

首先第 1 個 SRP 就是

接下來第 2、3 的 ISP、DIP 後變成如下，我會將 ISP 可降低使用者與依賴的情境是因為，元件如果用了 ISP，而不是建立包山包海的介面，那就大大可以減少使用者支援的情境數量與角色。而元件所依賴的元件，如果也使用了 ISP，那事實上就代表它變動的情況也變好，所以我覺得它可以同時減少兩方的變動。

然後接下來的 OCP 它希望可以使用擴展的方式來避免修改，而所引起的變動，所以圖會在變成這樣，同樣如果元件與依賴元件都用這個原則來設計，那就代表變動都會減少。

然後最後一個是 LSP，它主要的原則就是，IS-A 是以行為，也就是任何用子類別的地方，都可以替代成母類別，然後這裡我覺得使用了它可以減少到使用者變動，因為有提到，如果子類別不可替換，那就代表那個子類別有特殊處理，這也代表外面使用者可能會需要根據這個特例，來進行 ifelse 判斷與修改。

聚合性三大原則與耦合性三大原則

然後接下來我們加入聚合性三大原則 :

• 重用性-發布等價原則（REP:Reuse/Release Equivalence Principle）
• 共用封閉原則（CCP:Common Closure Principle）
• 共同重複使用原則（CRP:Common Reuse Principle）

然後有一點要先說 :

聚合這三個原則，都是 base 在解耦的前提，也就是說它希望在不影響其它元件情況下，越能聚合越好

REP 我目前想不到太多的關連性，先跳過。

然後先來談談 CCP 與那幾個的關係。首先複習一下 CCP 的原則主要是在說 :

CCP: 經常一起變化的元件，就應該放在一起，因為他們的變化原因可能很相同

CRP: 經常一起被使用的類別應該放在一起，包含依賴的東西。但反過來說不被依賴的就不要包在一起。

SRP 中，我有提到元件會變動的兩個理由為 :

• 使用者與情境
• 依賴的元件

然後我想了一下，我應該會多加一個 :

• domain 的關係，例如 order 與 suborder。

所以這裡事實上我覺得有點導出兩種將一個已經很大的 userService 的切分方向 :

1. 使用者與情境 ( 例如這個 userService 現在有給創作者與員工的情境使用，那是不是就可以拆兩個 ? )
2. 共同依賴的東西 ( 例如 userService 有依賴了 n 個 repository，那我是不是可以根據依賴的 repository 在切分呢 ? )
3. domain 的關係比較是算 domain driven design 的切分，這裡放在後面會說。

但其中第 2 點，我自已是建議，不是每一個 repository 都要切成一個 service，而且發現某個 service 太大了，然後接下來觀查有沒有那些群的 repository，是幾乎一起出現的，例如 userService 裡有 userInvoiceRepository, userPaymentRepoistory，那這樣就可以拉出一個 userPurchaseService 然後裡面有這兩個 repository。

然後我覺得 CCP 與 CRP 都有包含在上面說的情境下。

設計原則總結心得列表

• 一個大方法、大類別、或是模組要拆分時，可以從共同依賴與使用情境兩方面來開始下手。(SRP)
• 是否有過於龐大的 interface ? 是否可以使用情境來拆分? (DIP)
• 是否依賴於抽象而不是具體實現 ? (ISP)
• 低層級模組是否依賴高層級抽象而不是具體實作 ? (ISP)
• 儘可能用擴展來替代修改，通常可以先往繼承與擴展來增加功能。 (OCP)
• 每個子類別的行為 (is-a 是以行為判斷)是否都符合母類的使用情境，這樣就可以避免外使用情境那的變動。(LSP)
• 經常一起變動的類別就應該放在一起，然後通常變動源就是使用情境與依賴元件，可以用這個來決定那些該放在一起。(SRP、CCP)
• 經常一起被使用的類別應該放在一起。(CRP)
• 不要有循環依賴，因為這代表結構有問題，而且炸了一個會一直連鎖變動 (ADP)。
• 一個元件應該依賴比自已更穩定的元件。(SRP、SDP)
• 不是所有的東西都是要抽象的，穩定的才要抽象，而不穩定的就具體(SAP)