面向對象五大原則：
(1)單一職責原則（Single-Resposibility Principle）
•一個類應該僅有一個引起它變化的原因
職員類例子： 比如在職員類裏，將工程師、銷售人員、銷售經理這些情況都放在職員類裏考慮，其結果將會非常混亂，在這個假設下，職員類裏的每個方法都要ifelse判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員類型，不論哪一種發生需求變化，都會改變職員類！這個是大家所不願意看到的！
(2)開放封閉原則（Open-Closed principle）
•對擴展是開放的，對更改是封閉的！
變化來臨時，如果不必改動軟件實體裁的源代碼，就能擴充它的行爲，那麼這個軟件實體設計就是滿足開放封閉原則的。如果說我們預測到某種變化，或者某種變化發生了，我們應當創建抽象類來隔離以後發生的同類變化。
(3)里氏替換原則（Liskov-Substituion Principle）
•子類可以替換父類並且出現在父類能夠出現的任何地方,貫徹GOF倡導的面向接口編程
在這個原則中父類應儘可能使用接口或者抽象類來實現！
子類通過實現了父類接口，能夠替父類的使用地方！
通過這個原則，我們客戶端在使用父類接口的時候，通過子類實現！
意思就是說我們依賴父類接口，在客戶端聲明一個父類接口，通過其子類來實現
這個時候就要求子類必須能夠替換父類所出現的任何地方，這樣做的好處就是，在根據新要求擴展父類接口的新子類的時候而不影響當前客戶端的使用！
(4)依賴倒置原則（Dependecy-Inversion Principle）
•傳統的結構化編程中，最上層的模塊通常都要依賴下面的子模塊來實現，也稱爲高層依賴低層！
所以DIP原則就是要逆轉這種依賴關係，讓高層模塊不要依賴低層模塊，所以稱之爲依賴倒置原則！
(5)ISP 接口隔離原則(Interface-Segregation Principle)
•使用多個專門的接口比使用單個接口要好的多！
這個我有體會，在我實際編程中，爲了減少接口的定義，將許多類似的方法都放在一個接口中，最後發現，維護和實現接口的時候花了太多精力，而接口所定義的操作相當於對客戶端的一種承諾，這種承諾當然是越少越好，越精練越好，過多的承諾帶來的就是你的大量精力和時間去維護！