原文地址：LoveDev
在學習設計模式之前，需要了解一下面向對象的六大原則乡小，設計模式大多都遵循這些原則阔加，寫代碼時心中時刻不要忘記六大原則，利用它們能寫出更整潔满钟、低耦合胜榔、高內聚的代碼，更加清晰的邏輯
該文章由網上以及書籍上的資料整理而來 :)
<h1 id="SRP"> 單一職責原則 </h1>
Single Responsibility Principle湃番，簡稱SRP夭织，對一個類而言，應該僅有一個引起它變化的原因吠撮，即一個類只負責一項職責
問題描述
當類 C 負責兩個不同的職責：職責 M1尊惰，職責 M2，職責 M1 需求發(fā)生改變需要改變類 C 的時候，很有可能影響到原先的職責 M2 的功能
解決方案
一個類只負責一個職責弄屡，當需求改變時题禀，不會影響到其他職責
<h1 id="LSP"> 里氏替換原則 </h1>
Liskov Substitution Principle，簡稱LSP膀捷，所有引用基類的地方必須能透明地使用其子類的對象
問題描述
有一個功能 M迈嘹，由類 C 完成，由于業(yè)務需要全庸，需要拓展 M 功能 M1秀仲，此時需要由類 C 的子類 C1 完成拓展功能，當 C1 完成 M1 功能的同時壶笼，有可能導致原來 M 功能不可用
解決方案
當使用繼承時神僵，遵循里氏替換原則。類 M1 繼承類 M 時覆劈，除添加新的方法完成 M1 的新增功能外保礼，盡量不要重寫父類 C 的方法，也盡量不要重載父類 C 的方法
繼承作為面向對象三大特性之一责语，在給程序設計帶來巨大便利的同時氓英，也帶來了弊端。比如使用繼承會給程序帶來侵入性鹦筹，程序的可移植性降低，增加了對象間的耦合性址貌，如果一個類被其他的類所繼承铐拐，則當這個類需要修改時，必須考慮到所有的子類练对，并且父類修改后遍蟋，所有涉及到子類的功能都有可能會產生故障
<h1 id="DIP"> 依賴倒置原則 </h1>
Dependence Inversion Principle，簡稱DIP
- 高層模塊不應該依賴低層模塊螟凭，高層模塊是調用類虚青，低層模塊是實現(xiàn)類
- 二者都應該依賴其抽象，抽象指接口或抽象類
- 細節(jié)應該依賴抽象螺男，細節(jié)指實現(xiàn)類
問題描述
有 B 和 C 兩個實現(xiàn)類棒厘，類 A 直接依賴類 B，這種場景下下隧，類 A 一般為高層模塊奢人，負責復雜業(yè)務邏輯，類 B 和類 C 是低層模塊淆院，負責原子操作何乎，如果需要把類 A 改為依賴類 C，必須通過修改類 A 源代碼，可能會引入不必要的風險
Tip：
- 原子操作：不可分割的支救，在執(zhí)行完畢之前不會被任何其它任務或事件中斷的操作
解決方案
將類 A 修改為依賴接口 I 抢野，類 B 和類 C 各自實現(xiàn)接口 I ，類 A 通過接口 I 間接與類 B 或者類 C 發(fā)生聯(lián)系各墨，則會大大降低修改類A的幾率
示例代碼：
interface Animal{
public String getFood();
}
class Cat implements Animal {
@Override
public String getFood() {
return "魚";
}
}
class Dog implements Animal{
@Override
public String getFood() {
return "骨頭";
}
}
class Master {
// 依賴Animal接口
public void feed(Animal animal) {
String food = animal.getFood();
}
}
<h1 id="ISP"> 接口隔離原則 </h1>
Interface Segregation Principle指孤，簡稱ISP，一個類對另一個類的依賴應該建立在最小的接口上
問題描述
類 A 通過接口 I 依賴類 B欲主，類 C 通過接口 I 依賴類 D邓厕，如果接口 I 對于類 A 和類 B 來說不是最小接口，則類 B 和類 D 必須去實現(xiàn)他們不需要的方法
解決方案
將臃腫的接口I拆分為獨立的幾個接口扁瓢，類A和類C分別與他們需要的接口建立依賴關系详恼。也就是采用接口隔離原則
<h1 id="LoD"> 迪米特法則 </h1>
Law of Demeter，簡稱LoD引几，也稱為最少知識原則（Principle of Least Knowledge）或得墨忒耳定律昧互，一個對象應該對其他對象保持最少的了解
問題描述
類與類之間的關系越密切诅愚，耦合度越大拢蛋，當一個類發(fā)生改變時助析，對另一個類的影響也越大
解決方案
盡量降低類與類之間的耦合
<h1 id="OCP"> 開閉原則 </h1>
Open Close Principle倘待，簡稱OCP飒货，對象應該對擴展開放批狐，對修改關閉瓮下，開閉原則是面向對象設計中最基礎的設計原則
問題描述
在軟件的開發(fā)工程中记劈，因為需求變化盖腕，升級赫冬，重構和維護等原因，需要修改源代碼溃列，這樣很有可能引入錯誤
解決方案
當軟件有變化時劲厌，盡量通過擴展的行為實現(xiàn)變化，而不是通過修改已有的代碼實現(xiàn)變化
