前言
我們都知道面向對象有六大原則，23種設計模式。它們可以指導我們如何寫出更加優秀的代碼。六大原則是基礎，我們面向對象編程應該盡量遵從這六大原則，才能寫出優秀的代碼。
23種設計模式是前人為我們總結出的解決某一類問題的辦法，通過使用這些模式，我們可以更好的解決這一類問題。當然 23 種設計模式的設計前提也是建立在六大原則基礎之上的。
目錄
六大原則概念
六大原則是面向對象的六大原則，也就是說，我們在編寫面向對象語言的時候，只有遵守了這六大原則才能寫出真正的面向對象。才能擁有面向對象的思想。我們寫的代碼符合了這六大原則，有助有提高我們代碼的質量，寫出可擴展、可維護、可讀性好、低耦合、高內聚的代碼。
當然不符合這些原則，同樣也是可以寫代碼的，只不過寫出的代碼質量就沒有保證了，只能說勉強算是個代碼。這好比做人一樣，人也是有原則的，符合了這些原則，那就可以做一個堂堂正正的好人，不符合這些原則，也能活着。但是當不斷的觸犯原則，最后成了一個沒有原則的人了，那么結果顯然可見。如果隨着程序不斷的變大，代碼不斷的沒有原則，那么最終的結果就是你的程序無法進行下一步維護了。
總之我們在寫代碼的時候要盡量符合這些原則！才能寫出高質量代碼！
單一職責
單一職責是我們優化代碼的第一步
概念
概念：就一個類而言，應該僅有一個引起它變化的原因
概念可能不太好懂，簡單來說就是一個類中應該是一組相關性很高的函數、數據的封裝。
下面舉例子：
public class Activity{
// 請求網絡加載
public void requestNet(){
String url = editText.getText();
String parmas = editText.getText();
// 判斷是否符合某個條件
if(xx){
}
// 繼續判斷
if(xxx){
}
.... 等等省略1000行
}
class Adapter{
}
// 數據類
class Data{
}
class Xxx{
}
.....
}
像上面的例子就是一個很好的反例代表，把所有的職責全部放到了 Activity 中，把所有的函數功能都放到了 requestNet 中。這樣勢必造成 Activity 異常的臃腫，只要一個職責發生變化就能引起 Activity 的變化。比如 Adapter 變化，要去 Activity 中修改，等等都會對 Activity 造成變化。requestNet 函數中的功能不夠純粹，里面又包含了很多其他的功能，也會導致同樣的問題。
這也就是概念中提到的，就一個類而言，應該僅有一個引起它變化的原因。
好處
單一職責的好處很明顯，讓一個類、函數只負責某一項任務或者功能，可以達到很好的復用效果，代碼的可讀性也會增強，可讀性好了，對應的可維護性也會增加。
當然關於職責的划分是一個很抽象的概念，每個人的划分都會不同，單一職責的划分界限並不總是那么清晰，有的時候划分的很細也會帶來不方便。這是一個靈活掌握的問題，關鍵是設計代碼的時候有沒有考慮到這種思想。
開閉原則
Java 世界里最基礎的設計原則，指導我們如何建立一個穩定的、靈活的系統。
概念
軟件中的對象（類、模塊、函數等）應該對於擴展是開放的，但是對於修改是封閉的。
在編寫代碼的過程中，不是一成不變的，需求的變化、升級、維護等等都需要對代碼進行修改，修改的時候就不可避免地將錯誤引入原本已經測試過的舊代碼中，破壞原有系統。因此，當軟件需求發生變化的時候，我們應該優先考慮通過擴展的方式來實現變化，而不是通過修改已有代碼來實現。
當然實際開發中擴展和修改是同時存在的。應該盡量少的去修改代碼，想法去擴展代碼。
《面向對象軟件構造》一書中提到這一原則---開閉原則。這一想法認為，程序一旦開發完成，程序中的一個類的實現只應該因錯誤而被修改，新的或者改變的特性應該通過新建不同的類實現，新建的類可以通過繼承的方式來重用原有類。
舉個簡單的例子：
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 來判斷要調用那一個，如果繼續添加其他顏色的筆就繼續添加。這樣貌似不錯。但是試想 Hello 是你提供給別人的一個框架，那么別人想要繼續添加可以寫出黃色的 Hello Wrold ，是不是就沒有辦法了，非得讓你去修改 Hello 方法才可以，沒有了擴展性。
現在優化成
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 內的代碼了。
開閉原則，對修改關閉，對擴展開放。並不是說完全的不能修改，比如上面內容，一開始只有一個 BlackPen 的時候，你沒有想到擴展，可以那樣寫，但是隨着業務變化，出現了不同的 Pen。這個時候就需要考慮 Pen 要有可擴展性。就不能重復的在 Hello 類中不斷去修改了。而是換一種思路，讓其變得具有可擴展。
好處
可以使用我們的程序更加穩定，避免修改帶來的錯誤，增加可擴展性。當一個類中的業務不斷的發生變化需求，不斷的增加業務判斷，就需要考慮到擴展性了。
里氏替換原則
構建擴展性更好的系統
概念
所用引用基類的地方必須能透明地使用其子類的對象。
只要父類能出現的地方，子類就可以出現，而且替換為子類也不會產生任何錯誤或者異常，使用者可能根本就不需要知道是父類還是子類。
里氏替換原則就是依賴於繼承、多態這兩大特性。
其實就是將依賴變成抽象，不依賴於具體的實現。
比如：
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 的具體對象都是可以的。
好處
提高擴展性，使其不依賴具體的實現，依賴抽象。
依賴倒置原則
讓項目擁有變化的能力
概念
依賴倒置原則指代了一種特定的解耦形式，使得高層次的模塊不依賴於低層的模塊的實現細節，依賴模塊被顛倒了。
依賴倒置的關鍵點：
- 高層模塊不應該依賴低層模塊，兩者應該依賴其抽象
- 抽象不應該依賴細節
- 細節應該依賴抽象
在 Java 語言中，抽象就是指接口或抽象類。兩者都是不能直接被實例化的；細節就是實現類，實現接口或者繼承抽象類而產生的類就是細節。
高層模塊就是調用端，低層模塊就是具體的實現類。也就是調用端不要依賴具體的實現類，而是通過依賴抽象的方式。其實就是面向接口編程。
其實和上面里氏替換原則類似
好處
降低耦合性，不依賴具體細節，依賴抽象，提高可擴展性
接口隔離原則
系統有更好的靈活性
概念
客戶端不應該依賴它不需要的接口。另一種定義：類間的依賴關系應該建立在最小的接口上。接口隔離原則將非常龐大、臃腫的接口拆分成更小的和更具體的接口，這樣客戶將會只需要知道他們感興趣的方法。接口隔離原則的目的是系統解開耦合，從而容易重構、更改和重新部署。
其實就是讓一個接口盡可能的小，方法少，使用戶使用起來方便。
比如：一個對象實現了多個接口，有個接口是關閉功能，那么當這個對象想要關閉的時候，調用關閉方法就可以了，因為它實現了多個接口，有多個方法，調用的時候就暴露了其他接口函數。這個時候我們僅需要它暴露關閉的接口就可以了，隱藏其他接口信息。
好處
使用起來更加方便靈活
迪米特原則
概念
迪米特原則也稱為最少知道原則。一個對象應該對其他對象有最少的了解。通俗地講，一個類應該對需要耦合或調用的類知道得最少，類的內部如何實現與調用者或者依賴者沒有關系，調用者或者依賴者只需要知道它的需要的方法就可以了，其他的可一概不管。類與類之間關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
迪米特原則還可以解釋為：只與直接朋友通信。
也就是說，應該盡可能少的與別的朋友通信，僅與最直接的朋友通信。
兩個對象成為朋友的方式有多種：組合、聚合、依賴等等。
好處
降低依賴、使用簡單
總結
這六大原則不是相互獨立的，而是互相融合，你中有我，我中有你。
單一職責告訴我們要盡量的分離代碼，不斷的精分代碼，不同的模塊實現不同的功能。這樣不會所有功能都融合在一塊，方便閱讀、維護代碼。
開閉原則、里氏替換原則、依賴倒置原則：本質上都是通過抽象來提高擴展性。不依賴具體的實現而依賴抽象，就會增加很多擴展性，抽象可以有需要不同的實現。
接口隔離原則：和單一職責有類似，就是通過接口細分化，暴露最少的方法。要想有某個功能，只需要實現這個接口就可以了，與其他接口無關。
迪米特原則：盡量依賴更少的類，盡量對外界暴露更少的方法
實現這六大原則主要是通過面向接口編程，面向抽象編程。不依賴具體的實現。每個類都有一個抽象（抽象類、接口）。當高層級模塊需要依賴這個類的時候，依賴它的抽象，而不是具體。這個時候就可以靈活的改變其實現了。