SOLID設計原則
SRP
Single Reposibility Principle 單一職責原則
A class should have one,and only one,reason to change.
- 就一個類而言，有且僅有一個引起它變化的原因。
- 每個類都必須要有一個唯一的明确的職責，隻做一件事，并且把這件事做好。
- 僅當某種情況發生時（通常與這個類的職責直接相關）才需要修改這個類的代碼。
- 類名和方法名應該與其所承擔的職責相符。
示例
分離關注點，讓其彼此獨立。
OCP
Open Closed Principle 開放-封閉原則
Software entities(classes,modules,functions,etc) must be open for extension but closed for modification.
軟體實體（類，子產品，函數方法等）應該對擴充開發，對修改封閉。
- 一個軟體當需要擴充其功能時不要修改原來的代碼，而應該派生出新類。
- 僅當源代碼有Bug時，才對原始程式進行修改。
- 為了在修改現有代碼時不引入新的Bug。
示例
建立一個MyClass2類用以完全地替換掉MyClass類，如下所示：
LSP
Liskov Substitution Principle Liskov替換原則
Subtypes must be substituable for their base types.
子類型必須能夠替換掉他們的基類型。
- 當從一個類派生出子類時，所有使用其基類的代碼，在接收一個子類對象時都應該能正常工作，而不會出現錯誤或崩潰。
- 在具體實作上，要求應該針對接口或抽象基類進行程式設計，充分利用面向對象的多态特性，讓實作同一接口或抽象基類的子對象可以互相取代而不影響到程式的其它部分。
- 基于封裝與抽象出來的接口與抽象基類來開發上層應用具有穩定性。
示例：反例
ISP
Interface Segregation Principle 接口隔離原則
No client should be forced to depend on methods it does not use.
不應該強迫一個軟體元件依賴于它們不用的方法。
要避免建立一個全能接口，而應該将其定義的功能從邏輯上進行分組，将切分為多個小的接口。
各個類可以依據實際情況選擇實作不同的接口，而在不同的場景下，實作多個接口的對象又可以向外界展示出不同的特性。
示例
對于一個僅提供查詢功能的類來說
Save()
、
Update()
等方法是毫無意義的。
僅實作查詢接口的Repository類，如下所示：
DIP
Dependency Inversion Principle 依賴倒置原則
- High-level modules should not depend on low-level modules.Both should depend on abstractions.
- 高層子產品不應該依賴于底層子產品，兩者都應該依賴于抽象。
- Abstractions should not depend upon details.Details should depend upon abstractions.
- 抽象不應該依賴于細節，細節應該依賴于抽象。