1.單一職責原則
一個類中應該是一組相關性很高的方法、數據和封裝。明顯不一樣的功能就不應該放在一個類中。方法、接口等同理。
>>開始適應時可以先對要實現的內容用UML圖整理一下，根據UML圖來進行解耦、拆分。
2.開閉原則
軟件中的對象應該對于擴展是開放的，對于修改是封閉的。
當軟件/應用需要修改/變化時，應該盡量通過擴展的方式來實現變化，而不是通過修改已有的代碼來實現。
>>通過抽象類、接口等來實現擴展的部分。
3.里氏替換原則
簡單定義：所有引用基類的地方都必須能透明地使用其子類的對象。
開閉原則和里氏替換原則往往一起體現。
4.依賴倒置原則
關鍵點：
（1）高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象
（2）抽象不應該依賴細節
（3）細節應該依賴抽象
抽象：指抽象類、接口等不能直接被實例化的對象
細節：實現類，即可以直接被實例化的對象。
低層模塊：具體實現類
高層模塊：調用端
實際上，低層模塊和高層模塊都是抽象的實例
5.接口隔離原則
客戶端不應該依賴它不需要的接口，即類間的依賴關系應該建立在最小的接口上。
6.迪米特原則/最少知識原則
一個對象應該對其他對象有最少的了解，即調用者或依賴者只需要知道它需要的方法即可。
【個人思考】
陳述1：
繼承的缺點：繼承是侵入性的，只要繼承就必須擁有父類的所有屬性和方法，因此可能造成子類代碼冗余、靈活性降低。
推論1：
在不清楚該用接口還是用擴展類來實現的時候，可以從這個方面考慮：如果同類的擴展的功能需要依賴父類的地方較多，則用子類的方法實現；反之則用不同的類implements同一個接口來實現。
——2017.7.27
