通用原則 OCP（開閉原則）

架構設計的主導原則。設計良好的軟件應該易于擴展，同時抗拒修改。這是我們進行架構設計的主導原則，其它的原則都為這條原則服務。

USB接口滿足OCP原則，各個廠商可以擴展接口實現，但是不能修改接口定義

 正交性設計

“正交性”是從幾何學中借來的術語。如果兩條直線相交成直角，它們就是正交的。比如圖中的坐標軸。用向量術語說，這兩條直線互不依賴。沿著一條直線移動，你投影到另一條直線上的位置不變。

在計算技術中，該術語用于表示某種不相依賴性或是解耦性。如果兩個或更多事物中的一個發生變化，不會影響其他事物，這些事物就是正交的。在設計良好的系統中，數據庫代碼與用戶界面是正交的：你可以改動界面，而不影響數據庫；更換數據庫，而不用改動界面。提高生產效率，假定X組件能做M件事情，Y組件能做N件事情。如果他們是正交的，組合起來可以做M*N件事。

 下面給個示例，Foo和Bar接口是正交的，App類與Foo和Bar接口也是正交，它們之間互不影響

public interface Foo {
    void doSomethingX();
}

public interface Bar {
    void doSomethingY();
}

public class App {
    private Foo foo;
    private Bar bar;

    public App(Foo foo, Bar bar) {
        this.foo = foo;
        this.bar = bar;
    }

    /**
     * foo接口變化，不會影響到bar接口，也不會影響到app的實現。
     */
    public void doRightThing(){
        foo.doSomethingX();
        bar.doSomethingY();
    }
}

tips:設計功能的時候，功能之間需要正交；設計數據庫字段的時候，字段之間需要正交，禁止多維度的含義映射到一個字段，每個字段含義應該在一個維度上。

高內聚，低耦合　　

 抽象原則

抽象原則倡導通過精簡和概括來簡化實體：精簡指的是刪除不必要的細節，而概括指的是找出并定義通用的重要特征。

 正例：linux中一切都是文件。

封裝原則

封裝原則倡導通過隱藏抽象的實現細節和隱藏變化的等方法實現關注點分離和信息隱藏。

暴露出去的信息只是冰山一角

 模塊化

模塊化原則倡導通過集中和分解等手法創建內聚且耦合松散的抽象。

 正例：ElasticSearch模塊化

層次結構

層次結構原則倡導通過分類，概況，替換，排序等方法以層次方式組織抽象。

 正例：TCP/IP協議分層

代碼設計原則

SRP（單一職責原則）

任何一個軟件模塊，都應該有且只有一個被修改的原因，“被修改的原因“指系統的用戶或所有者，翻譯一下就是，任何模塊只對一個用戶的價值負責。該原則指導我們如何拆分組件。

LSP（里氏替換原則）

當用同一接口的不同實現互相替換時，系統的行為應該保持不變。該原則指導的是接口與其實現方式。

ISP（接口隔離原則）

不依賴任何不需要的方法、類或組件。該原則指導我們的接口設計。

當我們依賴一個接口但只用到了其中的部分方法時，其實我們已經依賴了不需要的方法或類，當這些方法或類有變更時，會引起我們類的重新編譯，或者引起我們組件的重新部署，這些都是不必要的。所以我們最好定義個小接口，把用到的方法拆出來。

DIP（依賴反轉原則）跨越組件邊界的依賴方向永遠與控制流的方向相反。該原則指導我們設計組件間依賴的方向。

依賴反轉原則是個可操作性非常強的原則，當你要修改組件間的依賴方向時，將需要進行組件間通信的類抽象為接口，接口放在邊界的哪邊，依賴就指向哪邊。

 組件構建原則

無依賴環原則

健康的依賴應該是個有向無環圖（DAG），互相依賴的組件，實際上組成了一個大組件，這些組件要一起發布、一起做單元測試。我們可以通過依賴反轉原則 DIP 來解除依賴環。

穩定依賴原則

依賴必須要指向更穩定的方向。

這里組件的穩定性指的是它的變更成本，和它變更的頻繁度沒有直接的關聯（變更的頻繁程度與需求的穩定性更加相關）。影響組件的變更成本的因素有很多，比如組件的代碼量大小、復雜度、清晰度等等，最最重要的因素是依賴它的組件數量，讓組件難以修改的一個最直接的辦法就是讓很多其他組件依賴于它！

組件穩定性的定量化衡量指標是：不穩定性（I） = 出向依賴數量 / (入向依賴數量 + 出向依賴數量)。如果發現違反穩定依賴原則的地方，解決的辦法也是通過 DIP 來反轉依賴。

穩定抽象原則

一個組件的抽象化程度應該與其穩定性保持一致。為了防止高階架構設計和高階策略難以修改，通常抽象出穩定的接口、抽象類為單獨的組件，讓具體實現的組件依賴于接口組件，這樣它的穩定性就不會影響它的擴展性。

組件抽象化程度的定量化描述是：抽象程度（A）= 組件中抽象類和接口的數量 / 組件中類的數量。

將不穩定性（I）作為橫軸，抽象程度（A）作為縱軸，那么最穩定、只包含抽象類和接口的組件應該位于左上角（0，1），最不穩定、只包含具體實現類，沒有任何接口的組件應該位于右下角（1，0），他們連線就是主序列線，位于線上的組件，他們的穩定性和抽象程度相匹配，是設計良好的組件。位于（0，0）周圍區域的組件，它們是非常穩定（注意這里的穩定指的是變更成本）并且非常具體的組件，因為他們的抽象程度低，決定了他們經常改動的命運，但是又有許多其他組件依賴他們，改起來非常痛苦，所以這個區域叫做痛苦區。右上角區域的組件，沒有其他組件依賴他們，他們自身的抽象程度又很高，很有可能是陳年的老代碼，所以這個區域叫做無用區。

轉自：

https://blog.csdn.net/csujiangyu/article/details/104017063