買了很多書，也看了很多，但有一個毛病就是看的時候很明白，但是看過不久就忘了，可見溫故而知新是很重要的，所以想重拾上學時的習慣，記筆記好了，經常來看看，記錄下看的時候的心得、體會。鼓勵自己堅持下去

    OOP在java中很重要，提到OOP就會想到面向物件的六大原則，說實話我的android開發算是自學的，大學也不是學的計算機，所以計算機基礎不是特別厲害，當然就說明我的java功底薄弱呀，對面向物件一直停留在封裝、繼承、多型的瞭解階段，但我知道面向物件有多麼重要，所以先來理解一下它的六大原則。這裡按照讀書的順序來記錄我的理解。

    1.1 優化程式碼的第一步      單一職責原則（Single Responsibility Principles）

     讀了這一節，所謂一心不可二用，就我個人的理解單一職責原則就是對於一個類而言，它只專注於做一件事，即明確類的職責，比如我要展示一本書的詳情，就建立一個名為ActivityBookDetail的類，在類中只展示書籍詳情，展示書籍詳情就是這個類的職責，如果我在這個類中也要去展示一個電影的詳情，可想而知這個類的程式碼在閱讀、維護、修改方面有多麼的可怕。

     在這本書的例子就是小民要寫一個圖片載入器的案例，在案例中小民的ImageLoader類在最初狀態不僅要完成載入圖片的功能，還包含了處理圖片快取的程式碼，由此可見這個類做了不止一件事，所以違背了單一職責原則，小民經過修改後在最初的ImageLoader類中提取出了一個圖片快取類ImageCache，在這個類中進行處理圖片快取的程式碼，哈哈哈，這就是單一職責呦。現在想想我在程式碼中總是把建立介面和編輯介面複用，類也複用，好不應該啊，不過如果用好這個原則應該是對需求功能仔細分析之後再確定一個類的職責是什麼。

    1.2 讓程式更穩定、更靈活    開閉原則（Open Close Principles）

    開閉原則，它是Java中最基礎的設計原則，聽到這個名字有點茫然，從名稱中看不出他開了什麼又閉了什麼，它的概念是：軟體中的物件（類、模組、函式等）應該對於拓展是開放的，但對於修改是封閉的。在實際的開發中，當需求有變更的時候，我們應該儘量去在原有的基礎上拓展（我理解的拓展就是可以把基礎的內容提取成介面、抽象類等，有實現類來實現、繼承），在拓展（實現類）中去修改、增加新的功能需求。想想我們的程式碼中總會有BaseActivity ，當建立新介面的時候，繼承BaseActivity，在新介面中去實現功能，而不是去BaseActivity中操作應該也是一種開閉原則吧（個人觀點，如若不對請指正）。

      在這本書中，還是小民在實現了第一節功能後，需要新增SD卡快取和雙快取兩個新功能，小民一開始是把這兩個快取功能加到了ImageCache類中，同時ImageLoader類也做了相應的修改，可見這樣是不利於程式碼拓展的，如果每次加新的功能時，都要修改ImageLoader類，會讓ImageLoader類變得越來越複雜，bug的出現機率也就增大了。在主管的修改下，提取出一個介面，介面定義了獲取圖片和存放圖片的方法（仔細分析這兩個方法其實就是快取類需要對外提供的，有了這兩個方法就能實現圖片的展示和快取，在ImageLoader中也只是專注於這兩個方法來實現功能而已，不用關心快取是怎麼做的），這樣所有的快取類不管是記憶體快取、SD卡快取還是雙快取的類，都實現基礎介面，實現相應的方法，拓展功能，就使的程式碼看起來簡潔多了，以後再有變動也利於拓展功能。當然了原始類也是可以修改的，只是儘量不去改而已。

      這個原則充分體現了抽象的重要性呀。

    1.3 構建拓展性更好的系統  里氏替換原則（Liskov Substitution Principles）

       里氏替換原則：所有引用基類的地方必須能透明的使用其子類的物件，這個很簡單的就可以看出這個原則的核心是抽象，而抽象又依賴於繼承。如小民的例子中，當選小民的程式碼實現了開閉原則，在ImageLoader類中設定快取模式是這樣實現的

     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

       private ImageCahce mImageCache;//ImageCahce 是對外提供getBItmap和setImageUrl設定圖片快取的介面

       public void setImageCache(ImageCache cache){

       mImageCache=cache;//cahce是ImageCache的介面實現類

       }

     +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     ImageLoader imageLoader=new ImageLoader();

     imageLoader.setImageCache(new MemoryCache);//記憶體快取實現ImageCahce介面

     imageLoader.setImageCache(new DiskCache);//SD快取實現ImageCahce介面

     imageLoader.setImageCache(new DoubleCache);//雙快取快取實現ImageCahce介面

       簡單理解就是用抽象實現的功能，都能替換成它的子類來完成。比如在開發過程中所有的控制元件都可以定義成View，繼承View的控制元件就可以實現VIew所做的事。開閉原則和里氏替換原則往往傻傻的糾結在一起，通過里氏替換原則來實現拓展

     1.4 讓專案擁有變化的能力   依賴倒置原則（Dependence Inversion Princlples）

      這個原則說實話我看了2遍也不是很理解，依賴倒置原則指代了一種特定的解耦形式，使得高層次的模組不依賴於低層次的模組的實現細節的目的，依賴模組被顛倒了，

感覺都讀不通順不過經過作者分析，這個原則有三個關鍵點：

     a、高層模組不應該依賴底層模組，兩者都應該依賴抽象，高層次模組指呼叫端，低層模組指實現類

     b、抽象不應該依賴細節、細節應該依賴抽象    抽象指介面或抽象類   細節指實現類即底層模組

     在Java中它的具體體現就是模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係通過介面或抽象類實現，目的就是為了解實現類與實現類間的耦合，所以要依賴抽象而不依賴具體實現類

      1.5 系統有更高的靈活性   介面隔離原則（InterfaceSegregation Principles）

       介面隔離原則：客戶端不應該依賴它不需要的介面，即類間的依賴關係應該建立在最小介面上。我的理解就是把複雜的功能細節化，兒這些細節就是一小點一小點的介面，用最小化的介面實現類的細節使系統擁有更低的耦合性、更高的靈活性。

       1.6 更好的拓展性  迪米特原則（Law of Demeter）

        這個原則也叫最少知識原則：一個物件應該對其它物件有最少的瞭解。呼叫者或者依賴者只要知道它需要的方法即可，至於方法是如何實現的，實現方法的類需要做什麼，都不需要知道。知道的越少耦合度約低，當一個類發生變化的時候，對另一個類的影響越小 。感覺就是買菜和賣菜的人  ，買著不關心菜長在那塊地上，只要賣菜的有菜賣給我就好 貌似有點牽強，不過我是理解了。

     面向物件很高深，它的六大原則有的也很高深，不過重點是思維，靈活有效的運用這些原則，就可以在實現系統穩定性的前提下保持拓展性、高內聚、低耦合，在版本變更的過程中保持清晰、靈活、穩定的系統架構。所以在寫程式碼之前要學會分析，不要只為了實現功能來堆程式碼，完全不管後續的change，當然了我也明白靈活使用這些原則不是一朝一夕就可以的，需要時刻銘記著幾大原則、常思考、多應用。