乙個類有且只有乙個職責（為了同乙個目的），把東西分到不能再分。
對擴充套件開放，對修改關閉。
要修改外觀，只需要換件衣服就可以了，不需要把自己的**給弄掉
關鍵是把不變的東西抽象出來
子型別必須能夠替換他們的基類
鳥類，大雁繼承ok，鴕鳥繼承no，no fly。違反替換規則，應該將鳥類分為飛鳥和不飛鳥，然後再繼承
不遵守的話：
1.繼承混亂，若子類作為引數傳遞進基類的函式，後果難以推測
2.基於父類編寫的單元測試**無法成功用於子類
使用者不應該被迫依賴她們不適用的介面。
過於胖的介面復用性差，複雜度高，可維護性差。
將胖介面拆分
ibird（walk，eat，fly）==>
ibird(walk,eat)=>iflybird(fly)
高層次模組不應該依賴於低層次的模組，而是都應該依賴於它們的抽象層。
抽象層==> 標準／規範
是乙個「可插拔」的系統
汽車依賴於引擎或輪胎的規範而非具體的某一款。否則，發生故障只能找相應的引擎或輪胎替換，否則就會報廢
設計模式是常用的面相物件設計的方法，歸納總結出來的，是一種包含關係。
設計模式則是這些原則在某些特定和常用條件下的應用，並且做了一些標準化
OOD之物件導向設計原則
一 概述 物件導向有七大設計原則 單一職責原則 開閉原則 黎克特制代換原則 依賴倒轉原則 介面隔離原則 合成復用原則 迪公尺特法則。最主要的是 solid s 單一職責原則 o 開閉原則 l 黎克特制替換原則 i 介面隔離原則 d 依賴倒轉原則 二 物件導向設計原則 1 單一職責原則 上面這個圖，有...
論面向事件設計 EOD 和物件導向設計 OOD
2006年09月17日 01 51 00 把這兩個概念放在一起，確實不是很工整。但對於熱衷設計的我們，只要有用就行。首先來解釋這兩個概念。我給大家打個比方，假設你是乙個專案的專案經理。現在你手頭上有乙個任務，需要你去完成。你會怎麼去做呢？乙個選擇，是你自己完成所有任務。當然，如果你願意奪取你所有的手...
論面向事件設計 EOD 和物件導向設計 OOD
把這兩個概念放在一起，確實不是很工整。但對於熱衷設計的我們，只要有用就行。首先來解釋這兩個概念。我給大家打個比方，假設你是乙個專案的專案經理。現在你手頭上有乙個任務，需要你去完成。你會怎麼去做呢？乙個選擇，是你自己完成所有任務。當然，如果你願意奪取你所有的手下的機會的話。你是可以完成。這就是我們以往...