上篇回顧：上篇講到了依賴倒置原則(dip),講的不好還請見諒。上篇文末留下了乙個問題：「抽象不能依據具體，這樣的說法會在哪些例子裡被反駁呢？」對待這個問題我們先回顧下，為什麼說抽象不能依賴具體？抽象即我們說的介面，具體即我們說的實體類，博主愛祖國的大好河山，所以就以山為例，我們先抽象出「山」，再看，黃山有鬆，廬山有霧，崑崙山有雪，這些具體的山擁有的特性並不是每座山都具有的通性，所以介面山並不能依據某一座具體的山的特點來設計，所以說抽象不能依賴具體。但同時抽象又來自於具體，歸根結底，山的特性是從所有具體山里提取的。還記得「鴕鳥不是鳥」嗎？當我們說鳥會飛的時候，就要結合具體情況具體分析，因為並不是所有的鳥都會飛。大家可能會說，這怎麼辦呢？如果介面提取出來後，隨著應用範圍的擴大，發現並不具有普適性，一些特例開始出現，奈若何？這個時候介面隔離原則就發揮作用了。
介面隔離原則：
定義：介面隔離原則(isp)，英文全稱：inte***ce segregation principle。如何理解該原則呢？只要把「隔離」這個詞說明白了，這個原則就豁然開朗了。首先看看他拗口的定義：
簡單的說就是：把介面功能盡量細分，盡量讓介面變得單純且簡潔，需要什麼介面就繼承什麼介面，並且去繼承最原子，最小的介面。大家會覺得這個道理很明顯啊，不需要的介面我怎麼會用呢？確實如此，難點在，如何細分介面來讓他變得單純。
下面我們舉個例子看看isp的運用。以樓主的畢業設計「大學科研成果管理系統」為例，學生上傳科研成果，老師對科研成果統一管理，老師除了具有基本的增刪改查的許可權外，還需審批學生上傳的科研成果是否符合規範，是否合法：
inte***ce imanage()
boolean add(){}
......
}
boolean aprove(){}//審批
......}
現在我們來說下介面「隔離」的含義：盡量將介面的功能細分成最小元。這個最小的標準是什麼？拆分到多詳細才是合理的？答案是，沒有標準！完全根據業務的需要和經驗的積累，保持介面隔離的意識即可。介面過於細小，反而增加了系統的複雜性，只有多花些時間去思考和籌畫，才能準確地實踐這一原則。
建議：如何衡量介面的原子性，下面給出秦小波給出的幾點建議：
乙個介面只服務於乙個子模組或業務邏輯；通過業務邏輯壓縮介面中的public方法，介面時常去回顧，不斷讓方法變得精煉。如果發現介面需要拆分，那麼盡量去拆分，如果拆分代價太大，就採用介面卡的方式做中轉。不必完全按照別的的劃分方式，根據自己的業務邏輯來，只要心中有原則，你的設計就是最優秀的設計。多重繼承分離，通過介面多繼承來實現客戶端需求。
最後，每篇一問：
我們知道介面隔離原則和單一職責原則具有關聯性，立足的角度卻有不同。如果介面隔離原則和單一職責原則發生了衝突，魚和熊掌如何取捨？
設計模式六大設計原則之開閉原則
開閉原則 1 定義 乙個軟體實體如類 模組和函式應該對擴充套件開放，對修改關閉。2 問題由來 在軟體的生命週期內，因為變化 公升級和維護等原因需要對軟體原有 進行修改時，可能會給舊 中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有 經過重新測試。3 解決方案 當軟體需要變化時，盡量通...
設計模式之六大設計原則（一）
單一職責原則是我們設計模式中最簡單也是最容易理解的物件導向設計原則，我們先來看一下單一職責原則的定義 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。通俗來講就是乙個類它只負責單一的功能，切不可做的太多。在軟體中乙個類 大到乙個模組，小到乙個方法 如果所具有的功能越多，那麼它就越複雜，復用...
設計模式 六大設計原則
剛剛結束設計模式學習時，感覺哪哪的抓不住重點，雖然之前師傅給勾了寫比較重要的設計模式，但是給我的感覺設計模式怎麼全都乙個樣子。通過對一些文章的瀏覽，簡單的對設計原則總結了一下。設計模式，就是設計範例。是經典問題的解決方案，是可以讓學習者舉一反三的，有研究價值 有交流價值的例子。設計模式的本質是物件導...