1. 單一職責原則

像函式一樣，類應該儘量短小

每一個類應該有且僅有一條加以修改的理由。

系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個職責。只有一個修改的原因，並與少量其它類一起協同達成期望的系統行為。

2.內聚

類應該只有少量實體變數。類中的每個方法都應該操作一個或者多個這種變數。方法操作的變數越多，就越粘聚到類上。如果一個類中的每個變數都被每個方法所使用的，則該類具有最大的內聚性。

極大化的內聚不太可能，我們希望內聚性保持在較高位置。內聚性高，意味著類中的方法和變數互相依賴，互相結合成為一個整體。

//這是一個很好的內聚的例子
public class Stack {
  
 
private int topOfStack = 0;
  List<int> elements = new LinkedList<int>();
  public int size(){
     return topOfStack;
  }
   public void push(int element) {
     topOfStack++;
     elements.add(element);
  }
   public int pop() {
     if(topOfStack != 0 ) {
        int element  = elements[topOfStack];
        elements.remove(topOfStack);
        topOfStack
 
--;
        return element;
     }
  }
}

3. 保持高內聚性就會得到許多短小的類

舉例

4. 隔離修改，開閉原則

舉例,沒有遵守開閉原則的類設計（配置載入器，假設有從多種檔案型別載入配置的需求）

這樣的設計如果要再增加一個檔案型別/或者修改任一檔案型別的載入邏輯的支援，那麼必須修改ConfigurationLoader類，違反了單一職責原則。

增收開閉原則的類設計應該是

這樣的話，要新增一個檔案型別支援，只需新建一個子類。如果要修改一個檔案型別的載入邏輯，也只需要修改一個類。

5. 依賴倒置

我們應該儘量避免依賴具體實現，而是應該依賴介面。

這樣的設計不具有靈活性，ConsoleLogger是一個具體的實現。如果我想要將系統的Log全部替換為輸出到檔案，那麼所有耦合的地方都需要修改。

好的設計應該是依賴介面，而不是依賴實現。像如下這樣