在uml類圖中總共有 種圖示
對於類和介面，總共有兩種，下面只有一行表示方法的介面以及下面有兩行分別顯示屬性和方法的類。
2.1單一職責原則
就乙個類而言，應有且僅有乙個導致它被修改的原因。也就是說，我們在設計類時，應當盡量保證每乙個類只承擔一項工作的職責，只有當這項職責發生變化，我們才需要修改類。如果乙個類承擔了過多的職責，那麼在他的多個職責中無論哪乙個發生了變化，我們需要改變這個類的作用，都必須停下他所承擔的其他職責的工作，從而喪失效率，甚至由於**耦合而造成其他職責的破壞。
即如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當修改發生時，設計會遭受意想不到的破壞。
2.2開放-封閉原則
對於軟體實體（類、模組、方法等）應該可以擴充套件，但是不可修改。在做任何系統的時候，我們都不可能指望對其的需求會一直不變，那不科學也不現實。所以我們需要保證整個系統面對需求的變更可以相對容易修改，而不是每次需求的變化我們都需要推到現有的重來。
該原則的核心是，面對需求，對程式的改動是通過增加新**進行的，而不是更改現有**。但是無論模組多麼「封閉」，都會存在一些無法使之繼續封閉的情況。既然不可能完全封閉，設計人員必須對於他設計的模組應該對那種變化封閉做出選擇。他必須先猜測出最有可能發生變化的種類，然後構造抽象來隔離這些變化。
也就是說，當系統出現了乙個很小的需求變化時，我們就應該去考慮這一類變化的應對措施，對現有類進行抽象來提前做好防範。
即，當我們在寫第乙個**時，假設變化不會發生，一旦發生乙個變化，我們就應該建立抽象（利用繼承和多型）來應對這一類的變化。
因此，我們會希望在展開工作後不久就能夠知道我們以後可能會遭遇到什麼樣的需求變化，查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。
開放-封閉原則是物件導向設計的核心所在，遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，即可維護、可擴充套件、可復用、靈活性好。讓開發人員進隊程式中呈現出頻繁變化的哪些部分做出抽象。當然，對於應用程式中每個部分都刻意的進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
2.3黎克特制代換原則
在軟體中，把乙個父類替換成其任何乙個子類，程式的行為都應當沒有變化。比如說，鳥類我們一般會定義上能飛的方法，而鴕鳥不能飛，那麼在這種情況下，我們就不應該讓鴕鳥去繼承鳥類，因為如果我們需要使用鳥類的飛翔方法時，鴕鳥將會為我們帶來錯誤（bug）。
2.4依賴倒轉原則
針對介面程式設計，而不是針對實現程式設計。舉個例子，我們不能讓高層模組依賴於低層模組。
在面向過程開發時，為了能夠復用常用**，會把常用**寫成**庫。比如訪問資料庫，增刪改查一類。每次做新的專案時，我們就去呼叫這些**庫中的**，這就是高層模組依賴於低層模組。
而這種方式一旦低層模組出現問題，或者因為其他原因（比如客戶指定了資料庫而你的低層模組用的另乙個資料庫）無法使用時，會導致我們的高層模組，自己寫的模組也無法復用。
而我們在物件導向中，則應該讓兩者都依賴於介面或抽象類，畢竟由於黎克特制代換原則，我們繼承自介面和抽象類的實現類都必須能夠替換或者實現介面和抽象類的全部功能。這樣無論低層模組發生了什麼問題，我們也只需要根據介面去更換低層模組。
策略模式是一種定義一系列演算法的設計模式，從概念上來看，所有這些演算法完成的都是相同的工作（如在圖示中他們都具有acceptcash方法），只是實現不同，它可以以相同的方式呼叫所有的演算法，減少了各種演算法類與使用演算法類之間的耦合。
如圖，我們有三個正在執行的演算法，他們主要的方法為acceptcash()方法，它的返回值為乙個double型別的數值。
我們可以將acceptcash方法提出，寫在基類cashsuper中，讓這三個類作為其子類，讓另乙個類cashcontext作為和客戶端程式的介面，在其中引用父類cashsuper，通過判斷執行時的情況，將三個子類賦值給父類的變數，動態呼叫三個作為子類的演算法。
在執行中，這以設計模式經常和簡單工廠模式相結合，使「判斷並賦值」這一過程也在context類中完成，這樣就可以讓客戶端不必在認識基類cashsuper了。
//工廠類cashcontext的實現
public
class cashcontext
this.result = cs.acceptcash();//賦值完成後執行運算方法
}public
double
getresult()
裝飾模式是為已有的功能動態地新增更多功能的一種形式。而這些新加入的功能，經常是為了滿足在某種特殊情況下的特殊需要，僅僅是裝飾了現有的類和方法。
因此，我們需要一種模式來動態的在現有的類的方法的基礎上增加新的**。這就是裝飾模式。其構造如圖所示。
如圖中，我們想要擴充套件concretecomponent類，他有乙個介面是component，裡面包含了我們想要擴充套件的該類的方法operation()。之後我們寫乙個抽象類decorator，其中包含有擴充套件方法operation()，之後我們們可以建立類來繼承decorator類，在其中包含operation()方法。
decorator類的構造如下方**。除了我們要擴充套件的operation方法外，我們還需要乙個設定component的方法。
public
class
decorator
implements
component
public
void
operation()
}public component getfactory()
}
public
class
decoratora
extends
decorator
}
private
void
prepare()
大話設計模式讀書筆記一
1矩形框代表乙個類。如果類是抽象的，那麼要用斜體表示。第二層是字段和屬性。第三次是類的方法和行為。對應的屬性表示為 notation meaning public private protected 乙個例子就是 如果定義乙個介面。要在名稱上面加 介面也用棒棒糖語法表示 下面將類與類之間的關係。知道...
《大話設計模式》讀書筆記一
今天開始看大話設計模式，覺得通俗易懂，作為設計模式的入門書再好不過。很慚愧現在才說設計模式入門，作為不是軟體專業出身缺入了軟體行業的門的小菜，在工作後也用到了一些設計模式，但是卻沒有系統的學習，所以在讀的過程中，經常做恍然大悟狀，哦，原來叫這個名，哦，原來是這麼個原理，不過亡羊補牢，為時未晚，決定花...
讀書筆記 大話設計模式
大話設計模式 的確寫的很不錯。把晦澀解懂的設計模式，講的通俗易懂。邊讀邊用evernote做筆記，把印象深刻的整理了一下。先補習一下uml的圖示法 繼承，介面，組合，依賴，關聯 策略模式 strategy 定義一系列演算法，所有演算法完成的都是相同的工作，只是實現不同。減少演算法與使用類之間的藕合。...