說到 SOLID 原則，相信有過幾年工作經(jīng)驗的朋友都有個大概印象莺禁，但就是不知道它具體是什么留量。甚至有些工作了十幾年的朋友，它們對 SOLID 原則的理解也停留在表面哟冬。今天我們就來聊聊 SOLID 原則以及它們之間的關系。
什么是SOLID原則
SOLID 原則其實是用來指導軟件設計的忆绰，它一共分為五條設計原則浩峡，分別是：
- 單一職責原則（SRP）
- 開閉原則（OCP）
- 里氏替換原則（LSP）
- 接口隔離原則（ISP）
- 依賴倒置原則（DIP）
單一職責原則（SRP）
單一職責原則（Single Responsibility Principle），它的定義是：應該有且僅有一個原因引起類的變更错敢。簡單地說：接口職責應該單一翰灾，不要承擔過多的職責。 用生活中肯德基的例子來舉例：負責前臺收銀的服務員稚茅，就不要去餐廳收盤子纸淮。負責餐廳收盤子的就不要去做漢堡。
單一職責適用于接口亚享、類咽块，同時也適用于方法。例如我們需要修改用戶密碼欺税，有兩種方式可以實現(xiàn)侈沪，一種是用「修改用戶信息接口」實現(xiàn)修改密碼，一種是新起一個接口來實現(xiàn)修改密碼功能晚凿。在單一職責原則的指導下亭罪，一個方法只承擔一個職能，所以我們應該新起一個接口來實現(xiàn)修改密碼的功能歼秽。
單一職責原則的重點在于職責的劃分应役，很多時候并不是一成不變的，需要根據(jù)實際情況而定。單一職責能夠使得類復雜性降低箩祥、類之間職責清晰院崇、代碼可讀性提高、更加容易維護滥比。但它的缺點也很明顯亚脆，就是對技術(shù)人員要求高，有些時候職責難以區(qū)分盲泛。
我們在設計一個類的時候濒持，可以先從粗粒度的類開始設計，等到業(yè)務發(fā)展到一定規(guī)模寺滚，我們發(fā)現(xiàn)這個粗粒度的類方法和屬性太多柑营，且經(jīng)常修改的時候，我們就可以對這個類進行重構(gòu)了村视，將這個類拆分成粒度更細的類官套，這就是所謂的持續(xù)重構(gòu)。
開閉原則（OCP）
開閉原則（Open Closed Principle）蚁孔，它的定義是：一個軟件實體奶赔，如類、模塊和函數(shù)應該對擴展開放杠氢，對修改關閉站刑。簡單地說：就是當別人要修改軟件功能的時候，使得他不能修改我們原有代碼鼻百，只能新增代碼實現(xiàn)軟件功能修改的目的绞旅。
這聽著有點玄乎，我來舉個例子吧温艇。
這段代碼模擬的是對于水果剝皮的處理程序因悲。如果是蘋果，那么是一種撥皮方法勺爱；如果是香蕉晃琳，則是另一種剝皮方法。如果以后還需要處理其他水果邻寿，那么就會在后面加上很多 if else 語句蝎土，最終會讓整個方法變得又臭又長。如果恰好這個水果中的不同品種有不同的剝皮方法绣否，那么這里面又會有很多層嵌套誊涯。
if(type == apple){
//deal with apple
} else if (type == banana){
//deal with banana
} else if (type == ......){
//......
}
可以看得出來，上面這樣的代碼并沒有滿足「對拓展開放蒜撮，對修改封閉」的原則暴构。每次需要新增一種水果跪呈，都可以直接在原來的代碼上進行修改。久而久之取逾，整個代碼塊就會變得又臭又長耗绿。
如果我們對剝水果皮這件事情做一個抽象，剝蘋果皮是一個具體的實現(xiàn)砾隅，剝香蕉皮是一個具體的實現(xiàn)误阻，那么寫出的代碼會是這樣的：
public interface PeelOff {
void peelOff();
}
public class ApplePeelOff implement PeelOff{
void peelOff(){
//deal with apple
}
}
public class BananaPeelOff implement PeelOff{
void peelOff(){
//deal with banan
}
}
public class PeelOffFactory{
private Map<String, PeelOff> map = new HashMap();
private init(){
//init all the Class that implements PeelOff interface
}
}
.....
public static void main(){
String type = "apple";
PeelOff peelOff = PeelOffFactory.getPeelOff(type); //get ApplePeelOff Class Instance.
peelOff.pealOff();
}
上面這種實現(xiàn)方式使得別人無法修改我們的代碼，為什么晴埂？
因為當需要對西瓜剝皮的時候究反，他會發(fā)現(xiàn)他只能新增一個類實現(xiàn) PeelOff 接口，而無法再原來的代碼上修改儒洛。這樣就實現(xiàn)了「對拓展開放精耐，對修改封閉」的原則。
里氏替換原則（LSP）
里氏替換原則（LSP）的定義是：所有引用基類的地方必須能透明地使用其子類的對象琅锻。簡單地說：所有父類能出現(xiàn)的地方卦停，子類就可以出現(xiàn)，并且替換了也不會出現(xiàn)任何錯誤恼蓬。 例如下面 Parent 類出現(xiàn)的地方惊完，可以替換成 Son 類，其中 Son 是 Parent 的子類处硬。
Parent obj = new Son();
等價于
Son son = new Son();
這樣的例子在 Java 語言中是非常常見的专执，但其核心要點是：替換了也不會出現(xiàn)任何的錯誤。這就要求子類的所有相同方法郁油，都必須遵循父類的約定，否則當父類替換為子類時就會出錯攀痊。 這樣說可能還是有點抽象桐腌，我舉個例子。
public class Parent{
// 定義只能扔出空指針異常
public void hello throw NullPointerException(){
}
}
public class Son extends Parent{
public void hello throw NullPointerException(){
// 子類實現(xiàn)時卻扔出所有異常
throw Exception;
}
}
上面的代碼中苟径，父類對于 hello 方法的定義是只能扔出空指針異常案站，但子類覆蓋父類的方法時，卻扔出了其他異常棘街，違背了父類的約定蟆盐。那么當父類出現(xiàn)的地方，換成了子類遭殉，那么必然會出錯石挂。
其實這個例子舉得不是很好，因為這個在編譯層面可能就有錯誤险污。但表達的意思應該是到位了痹愚。
而這里的父類的約定富岳，不僅僅指的是語法層面上的約定，還包括實現(xiàn)上的約定拯腮。有時候父類會在類注釋窖式、方法注釋里做了相關約定的說明，當你要覆寫父類的方法時动壤，需要弄懂這些約定萝喘，否則可能會出現(xiàn)問題。例如子類違背父類聲明要實現(xiàn)的功能琼懊。比如父類某個排序方法是從小到大來排序阁簸，你子類的方法竟然寫成了從大到小來排序。
里氏替換原則 LSP 重點強調(diào)：對使用者來說肩碟，能夠使用父類的地方强窖，一定可以使用其子類，并且預期結(jié)果是一致的削祈。
接口隔離原則（ISP）
接口隔離原則（Interface Segregation Principle）的定義是：類間的依賴關系應該建立在最小的接口上翅溺。簡單地說：接口的內(nèi)容一定要盡可能地小，能有多小就多小髓抑。
舉個例子來說咙崎，我們經(jīng)常會給別人提供服務，而服務調(diào)用方可能有很多個吨拍。很多時候我們會提供一個統(tǒng)一的接口給不同的調(diào)用方褪猛，但有些時候調(diào)用方 A 只使用 1、2羹饰、3 這三個方法伊滋，其他方法根本不用。調(diào)用方 B 只使用 4队秩、5 兩個方法笑旺，其他都不用。接口隔離原則的意思是馍资，你應該把 1筒主、2、3 抽離出來作為一個接口鸟蟹，4乌妙、5 抽離出來作為一個接口，這樣接口之間就隔離開來了建钥。
那么為什么要這么做呢藤韵？我想這是為了隔離變化吧！ 想想看锦针，如果我們把 1荠察、2置蜀、3、4悉盆、5 放在一起盯荤，那么當我們修改了 A 調(diào)用方才用到 的 1 方法，此時雖然 B 調(diào)用方根本沒用到 1 方法焕盟，但是調(diào)用方 B 也會有發(fā)生問題的風險秋秤。而如果我們把 1、2脚翘、3 和 4灼卢、5 隔離成兩個接口了，我修改 1 方法来农，絕對不會影響到 4鞋真、5 方法。
除了改動導致的變化風險之外沃于，其實還會有其他問題涩咖，例如：調(diào)用方 A 抱怨，為什么我只用 1繁莹、2檩互、3 方法，你還要寫上 4咨演、5 方法闸昨，增加我的理解成本。調(diào)用方 B 同樣會有這樣的困惑薄风。
在軟件設計中饵较，ISP 提倡不要將一個大而全的接口扔給使用者，而是將每個使用者關注的接口進行隔離遭赂。
依賴倒置原則（DIP）
依賴倒置原則（Dependence Inversion Principle）的定義是：高層模塊不應該依賴底層模塊告抄，兩者都應該依賴其抽象。抽象不應該依賴細節(jié)嵌牺，即接口或抽象類不依賴于實現(xiàn)類。細節(jié)應該依賴抽象龄糊，即實現(xiàn)類不應該依賴于接口或抽象類逆粹。簡單地說，就是說我們應該面向接口編程炫惩。通過抽象成接口僻弹，使各個類的實現(xiàn)彼此獨立，實現(xiàn)類之間的松耦合他嚷。
如果我們每個人都能通過接口編程蹋绽，那么我們只需要約定好接口定義芭毙，我們就可以很好地合作了。軟件設計的 DIP 提倡使用者依賴一個抽象的服務接口卸耘，而不是去依賴一個具體的服務執(zhí)行者退敦，從依賴具體實現(xiàn)轉(zhuǎn)向到依賴抽象接口，倒置過來蚣抗。
SOLID 原則的本質(zhì)
我們總算把 SOLID 原則中的五個原則說完了侈百。但說了這么一通，好像是懂了翰铡，但是好像什么都沒記住钝域。 那么我們就來盤一盤他們之間的關系。ThoughtWorks 上有一篇文章說得挺不錯锭魔，它說：
- 單一職責是所有設計原則的基礎例证，開閉原則是設計的終極目標。
- 里氏替換原則強調(diào)的是子類替換父類后程序運行時的正確性迷捧，它用來幫助實現(xiàn)開閉原則织咧。
- 而接口隔離原則用來幫助實現(xiàn)里氏替換原則，同時它也體現(xiàn)了單一職責党涕。
- 依賴倒置原則是過程式編程與面向?qū)ο缶幊痰姆炙畮X烦感，同時它也被用來指導接口隔離原則。
簡單地說：依賴倒置原則告訴我們要面向接口編程膛堤。當我們面向接口編程之后手趣，接口隔離原則和單一職責原則又告訴我們要注意職責的劃分，不要什么東西都塞在一起肥荔。當我們職責捋得差不多的時候绿渣，里氏替換原則告訴我們在使用繼承的時候，要注意遵守父類的約定燕耿。而上面說的這四個原則中符，它們的最終目標都是為了實現(xiàn)開閉原則。
