六大原則
單一職責原則
里氏替換原則
依賴倒置原則
接口隔離原則
迪米特原則
開閉原則
單一職責
概念：對功能進行分類，代碼進行解耦
栗子：一個網(wǎng)絡請求框架大致分為：請求類，緩存類，配置類；不能把這三個功能混合在一起，必須分成三個類分別去實現(xiàn)不同的功能
里氏替換
概念：在繼承類時，除了擴展一些新的功能之外，盡量不要刪除或者修改對父類方法的引用，也盡量不要重載父類的方法
栗子：每個類都是Object的子類，Object類中有一個toString()的方法，假如子類重寫該方法并且返回null，這個子類的下一級繼承返回的都是null，那么在不同開發(fā)人員維護時可能考慮不到這個問題，并且很可能會導致程序崩潰
依賴倒置
概念：高層模塊不依賴低層次模塊的細節(jié)，高層次就是不依賴細節(jié)而是依賴抽象（不依賴具體的類，而是依賴于接口）
栗子：某個網(wǎng)絡框架為了滿足不同開發(fā)者的需求，即能使用高效的OkHttp框架，也可以使用原生的API。正所謂蘿卜白菜各有所愛，那么是如何進行切換的呢，這個時候需要面向接口編程思想了，把一些網(wǎng)絡請求的方法封裝成一個接口，然后分別創(chuàng)建OkHttp和原生API的接口實現(xiàn)類，當然也方便后續(xù)其他開發(fā)人員進行擴展其他網(wǎng)絡框架的應用
接口隔離
概念：在定義接口方法時應該合理化，盡量追求簡單最小，避免接口臃腫
栗子：在實際開發(fā)中，往往為了節(jié)省時間，可能會將多個功能的方法抽成一個接口，其實這設計理念不正確的，這樣會使接口處于臃腫的狀態(tài)，這時就需要合理的拆分接口中的方法，另外抽取成一個獨立的接口，避免原有的接口臃腫導致代碼理解困難
迪米特 | 最少知道
概念：一個對象應該對其他對象有最少的了解；一個類應該對自己需要耦合或調用的類知道得最少，類的內(nèi)部如何實現(xiàn)、如何復雜都與調用者或者依賴者沒關系，調用者或者依賴者只需要知道他需要的方法即可，其他的一概不關心。類與類之間的關系越密切，耦合度越大，當一個類發(fā)生改變時，對另一個類的影響也越大。只與直接的朋友通信。每個對象都必然會與其他對象有耦合關系，兩個對象之間的耦合就成為朋友關系，這種關系的類型有很多，例如組合、聚合、依賴等。
栗子：一般在使用框架的時候，框架的開發(fā)者會抽出一個類供外部調用，而這個主要的類像是一個中介一樣去調用框架里面的其他類，恰恰框架里面其他類一般都是不可訪問（調用）的，這個框架就遵守了迪米特原則，其他開發(fā)人員只關心調用的方法，并不需要關心功能具體如何實現(xiàn)
開閉
概念：類、模塊和函數(shù)應該對擴展開放，對修改關閉
栗子：在軟件的生命周期內(nèi)，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經(jīng)過重新測試，整個流程對開發(fā)周期影響很大，這個時候就需要開閉原則來解決這種問題，在前期代碼設計的時候，要盡量考慮擴展性，避免后續(xù)新增功能的時候需要引發(fā)代碼的重構
總結
單一職責原則告訴我們實現(xiàn)類要職責單一
里氏替換原則告訴我們不要破壞繼承體系
依賴倒置原則告訴我們要面向接口編程
接口隔離原則告訴我們在設計接口的時候要精簡單一
迪米特原則告訴我們要降低耦合
開閉原則是總綱，告訴我們要對擴展開放，對修改關閉
精品文章
如果不夠準確，請幫忙指出
這篇文章要是對你有幫助的話，記得點個贊
