向?qū)ο蟮牧笤瓌t
前言
我們都知道面向?qū)ο笥辛笤瓌t，23種設(shè)計模式。它們可以指導(dǎo)我們?nèi)绾螌懗龈觾?yōu)秀的代碼。六大原則是基礎(chǔ)，我們面向?qū)ο缶幊虘?yīng)該盡量遵從這六大原則，才能寫出優(yōu)秀的代碼。
23種設(shè)計模式是前人為我們總結(jié)出的解決某一類問題的辦法，通過使用這些模式六大原則基礎(chǔ)之上的。
目錄
六大原則概念
六大原則是面向?qū)ο蟮牧笤瓌t，也就是說，我們在編寫面向?qū)ο笳Z言的時候，只有遵守了這六大原則才能寫出真正的面向?qū)ο?。才能擁有面向?qū)ο蟮乃枷?。我們寫的代碼符合了這六大原則，有助有提高我們代碼的質(zhì)量，寫出可擴展、可維護、可讀性好、低耦合、高內(nèi)聚的代碼。
當然不符合這些原則，同樣也是可以寫代碼的，只不過寫出的代碼質(zhì)量就沒有保證了，只能說勉強算是個代碼。這好比做人一樣，人也是有原則的，符合了這些原則，那就可以做一個堂堂正正的好人，不符合這些原則，也能活著。但是當不斷的觸犯原則，最后成了一個沒有原則的人了，那么結(jié)果顯然可見。如果隨著程序不斷的變大，代碼不斷的沒有原則，那么最終的結(jié)果就是你的程序無法進行下一步維護了。
總之我們在寫代碼的時候要盡量符合這些原則！才能寫出高質(zhì)量代碼！
單一職責(zé)
單一職責(zé)是我們優(yōu)化代碼的第一步
概念
概念：就一個類而言，應(yīng)該僅有一個引起它變化的原因
概念可能不太好懂，簡單來說就是一個類中應(yīng)該是一組相關(guān)性很高的函數(shù)、數(shù)據(jù)的封裝。
下面舉例子：
public?class?Activity{
??//?請求網(wǎng)絡(luò)加載
??public?void?requestNet(){
????String?url?=?editText.getText();
????String?parmas?=?editText.getText();
????//?判斷是否符合某個條件
????if(xx){
????}
????//?繼續(xù)判斷
????if(xxx){
????}
????....?等等省略1000行
??}
??class?Adapter{
??}
??//?數(shù)據(jù)類
??class?Data{
??}
??class?Xxx{
??}
??.....
}
像上面的例子就是一個很好的反例代表，把所有的職責(zé)全部放到了 Activity 中，把所有的函數(shù)功能都放到了 requestNet 中。這樣勢必造成 Activity 異常的臃腫，只要一個職責(zé)發(fā)生變化就能引起 Activity 的變化。比如 Adapter 變化，要去 Activity 中修改，等等都會對 Activity 造成變化。requestNet 函數(shù)中的功能不夠純粹，里面又包含了很多其他的功能，也會導(dǎo)致同樣的問題。
這也就是概念中提到的，就一個類而言，應(yīng)該僅有一個引起它變化的原因。
好處
單一職責(zé)的好處很明顯，讓一個類、函數(shù)只負責(zé)某一項任務(wù)或者功能，可以達到很好的復(fù)用效果，代碼的可讀性也會增強，可讀性好了，對應(yīng)的可維護性也會增加。
當然關(guān)于職責(zé)的劃分是一個很抽象的概念，每個人的劃分都會不同，單一職責(zé)的劃分界限并不總是那么清晰，有的時候劃分的很細也會帶來不方便。這是一個靈活掌握的問題，關(guān)鍵是設(shè)計代碼的時候有沒有考慮到這種思想。
開閉原則
Java 世界里最基礎(chǔ)的設(shè)計原則，指導(dǎo)我們?nèi)绾谓⒁粋€穩(wěn)定的、靈活的系統(tǒng)。
概念
軟件中的對象（類、模塊、函數(shù)等）應(yīng)該對于擴展是開放的，但是對于修改是封閉的。
在編寫代碼的過程中，不是一成不變的，需求的變化、升級、維護等等都需要對代碼進行修改，修改的時候就不可避免地將錯誤引入原本已經(jīng)測試過的舊代碼中，破壞原有系統(tǒng)。因此，當軟件需求發(fā)生變化的時候，我們應(yīng)該優(yōu)先考慮通過擴展的方式來實現(xiàn)變化，而不是通過修改已有代碼來實現(xiàn)。
當然實際開發(fā)中擴展和修改是同時存在的。應(yīng)該盡量少的去修改代碼，想法去擴展代碼。
《面向?qū)ο筌浖?gòu)造》一書中提到這一原則---開閉原則。這一想法認為，程序一旦開發(fā)完成，程序中的一個類的實現(xiàn)只應(yīng)該因錯誤而被修改，新的或者改變的特性應(yīng)該通過新建不同的類實現(xiàn)，新建的類可以通過繼承的方式來重用原有類。
舉個簡單的例子：
public?class?Hello{
??BlackPen?pen?=?new?BlackPen();
??void?writeHello(){
????pen.write("hello?world");
??}
}
//?Pen?類可以寫出字
public?class?BlackPen{
??public?void?write(String?content){
????System.out.println("content");
??}
}
上面這個程序中我們可以通過 BlackPen 類寫出字，有一天需求變了要求寫出紅色的字。
public?class?Hello{
??BlackPen?pen?=?new?BlackPen();
??RedPen?redPen?=?new?RedPen();
??void?writeHello(String?flag){
????switch(flag){
????????"XXX":
????????????pen.wiite("hello?world");
????????"YYY":
????????????redPen.write("hello?world")
????}
??}
}
//?BlackPen?類可以寫出黑字
public?class?BlackPen{
??public?void?write(String?content){
????System.out.println(content);
??}
}
//?RedPen?類可以寫出紅字
public?class?RedPen{
??public?void?write(String?content){
????System.out.println(content);
??}
}
這樣寫通過 switch 來判斷要調(diào)用那一個，如果繼續(xù)添加其他顏色的筆就繼續(xù)添加。這樣貌似不錯。但是試想 Hello 是你提供給別人的一個框架，那么別人想要繼續(xù)添加可以寫出黃色的 Hello Wrold ，是不是就沒有辦法了，非得讓你去修改 Hello 方法才可以，沒有了擴展性。
現(xiàn)在優(yōu)化成
public?class?Hello{
??Pen?pen?=?new?BlackPen();
??public?void?setPen(Pen?pen){
????this.pen?=?pen;
??}
??void?writeHello(){
?????????pen.write("hello?world")
??}
}
public?interface?Pen{
??write(String?content);
}
//?BlackPen?類可以寫出黑字
public?class?BlackPen?implement?Pen{
??public?void?write(String?content){
????System.out.println(content);
??}
}
//?RedPen?類可以寫出紅字
public?class?RedPen?implement?Pen{
??public?void?write(String?content){
????System.out.println(content);
??}
}
這樣就可以擴展而不用修改 Hello 內(nèi)的代碼了。
開閉原則，對修改關(guān)閉，對擴展開放。并不是說完全的不能修改，比如上面內(nèi)容，一開始只有一個 BlackPen 的時候，你沒有想到擴展，可以那樣寫，但是隨著業(yè)務(wù)變化，出現(xiàn)了不同的 Pen。這個時候就需要考慮 Pen 要有可擴展性。就不能重復(fù)的在 Hello 類中不斷去修改了。而是換一種思路，讓其變得具有可擴展。
好處
可以使用我們的程序更加穩(wěn)定，避免修改帶來的錯誤，增加可擴展性。當一個類中的業(yè)務(wù)不斷的發(fā)生變化需求，不斷的增加業(yè)務(wù)判斷，就需要考慮到擴展性了。
里氏替換原則
構(gòu)建擴展性更好的系統(tǒng)
概念
所用引用基類的地方必須能透明地使用其子類的對象。
只要父類能出現(xiàn)的地方，子類就可以出現(xiàn)，而且替換為子類也不會產(chǎn)生任何錯誤或者異常，使用者可能根本就不需要知道是父類還是子類。
里氏替換原則就是依賴于繼承、多態(tài)這兩大特性。
其實就是將依賴變成抽象，不依賴于具體的實現(xiàn)。
比如：
public?class?Window{
??public?void?show(View?child){
????child.draw();
??}
}
public?abstract?class?View{
??public?abstract?void?draw();
??public?void?measure(int?width,int?height){
????//?測量視圖大小
??}
}
public?class?Button?extends?View{
??public?void?draw(){
????//?繪制按鈕
??}
}
public?class?TextView?extends?View{
??public?void?draw(){
????//?繪制文本
??}
}
Window 是依賴于 View 的，是一個抽象類，Window 是依賴于一個抽象，而不是具體的對象。這個時候傳入任何 View ?的具體對象都是可以的。
好處
提高擴展性，使其不依賴具體的實現(xiàn)，依賴抽象。
依賴倒置原則
讓項目擁有變化的能力
概念
依賴倒置原則指代了一種特定的解耦形式，使得高層次的模塊不依賴于低層的模塊的實現(xiàn)細節(jié)，依賴模塊被顛倒了。
依賴倒置的關(guān)鍵點：
高層模塊不應(yīng)該依賴低層模塊，兩者應(yīng)該依賴其抽象
抽象不應(yīng)該依賴細節(jié)
細節(jié)應(yīng)該依賴抽象
在 Java 語言中，抽象就是指接口或抽象類。兩者都是不能直接被實例化的；細節(jié)就是實現(xiàn)類，實現(xiàn)接口或者繼承抽象類而產(chǎn)生的類就是細節(jié)。
高層模塊就是調(diào)用端，低層模塊就是具體的實現(xiàn)類。也就是調(diào)用端不要依賴具體的實現(xiàn)類，而是通過依賴抽象的方式。其實就是面向接口編程。
其實和上面里氏替換原則類似
好處
降低耦合性，不依賴具體細節(jié)，依賴抽象，提高可擴展性
接口隔離原則
系統(tǒng)有更好的靈活性
概念
客戶端不應(yīng)該依賴它不需要的接口。另一種定義：類間的依賴關(guān)系應(yīng)該建立在最小的接口上。接口隔離原則將非常龐大、臃腫的接口拆分成更小的和更具體的接口，這樣客戶將會只需要知道他們感興趣的方法。接口隔離原則的目的是系統(tǒng)解開耦合，從而容易重構(gòu)、更改和重新部署。
其實就是讓一個接口盡可能的小，方法少，使用戶使用起來方便。
比如：一個對象實現(xiàn)了多個接口，有個接口是關(guān)閉功能，那么當這個對象想要關(guān)閉的時候，調(diào)用關(guān)閉方法就可以了，因為它實現(xiàn)了多個接口，有多個方法，調(diào)用的時候就暴露了其他接口函數(shù)。這個時候我們僅需要它暴露關(guān)閉的接口就可以了，隱藏其他接口信息。
好處
使用起來更加方便靈活
迪米特原則
概念
迪米特原則也稱為最少知道原則。一個對象應(yīng)該對其他對象有最少的了解。通俗地講，一個類應(yīng)該對需要耦合或調(diào)用的類知道得最少，類的內(nèi)部如何實現(xiàn)與調(diào)用者或者依賴者沒有關(guān)系，調(diào)用者或者依賴者只需要知道它的需要的方法就可以了，其他的可一概不管。類與類之間關(guān)系越密切，耦合度越大，當一個類發(fā)生改變時，對另一個類的影響也越大。
迪米特原則還可以解釋為：只與直接朋友通信。
也就是說，應(yīng)該盡可能少的與別的朋友通信，僅與最直接的朋友通信。
兩個對象成為朋友的方式有多種：組合、聚合、依賴等等。
好處
降低依賴、使用簡單
總結(jié)
這六大原則不是相互獨立的，而是互相融合，你中有我，我中有你。
單一職責(zé)告訴我們要盡量的分離代碼，不斷的精分代碼，不同的模塊實現(xiàn)不同的功能。這樣不會所有功能都融合在一塊，方便閱讀、維護代碼。
開閉原則、里氏替換原則、依賴倒置原則：本質(zhì)上都是通過抽象來提高擴展性。不依賴具體的實現(xiàn)而依賴抽象，就會增加很多擴展性，抽象可以有需要不同的實現(xiàn)。
接口隔離原則：和單一職責(zé)有類似，就是通過接口細分化，暴露最少的方法。要想有某個功能，只需要實現(xiàn)這個接口就可以了，與其他接口無關(guān)。
迪米特原則：盡量依賴更少的類，盡量對外界暴露更少的方法
實現(xiàn)這六大原則主要是通過面向接口編程，面向抽象編程。不依賴具體的實現(xiàn)。每個類都有一個抽象（抽象類、接口）。當高層級模塊需要依賴這個類的時候，依賴它的抽象，而不是具體。這個時候就可以靈活的改變其實現(xiàn)了。