UML+模式设计概述
轉自于：http://blog.csdn.net/rexuefengye/article/details/13020225
工程學：工程龐大到一定程度必須是用工程學方法，好比直接用水泥沙子建設實用的摩天大廈是極其困難的。
標準類模型：這或許是AI實現的必經之路吧！類似于Java托管代碼的實現方式...
UML軟件工程組織：狀態圖與流程圖
Uml圖的使用入門：http://www.open-open.com/lib/view/open1328059700311.html???? 來自于http://www.open-open.com
畫流程圖需要注意的幾個問題：http://developer.51cto.com/art/201007/209790.htm
詳細解釋各種圖：http://www.cnblogs.com/jiqing9006/p/3344221.html
一、設計模式分類：
? ? ? 按照目的來分，設計模式可以分為創建型模式、結構型模式和行為型模式。(分類如下表)
- ? ? ??創建型模式用來處理對象的創建過程；
- ? ? ??結構型模式用來處理類或者對象的組合；
- ? ? ??行為型模式用來對類或對象怎樣交互和怎樣分配職責進行描述。
表1-1
| 設計模式分類 | 說明 | 備注 | |
| 創建型模式 | 工廠方法模式 （Factory?Method?Pattern） | 定義一個創建產品對象的工廠接口，將實際創建工作推遲到子類中。 | ? |
| 抽象工廠模式 (Abstract?Factory?Pattern） | 提供一個創建一系列相關或者相互依賴的接口，而無需指定它們具體的類。 | ? | |
| 建造者模式 （Builder?Pattern） | 將一個復雜的構建與其表示相分離，使得同樣的構建過程可以創建不同的表示。 | ? | |
| 原型模式 （Prototype?Pattern） | 用原型實例指定創建對象的種類，并且通過拷貝這些原型創建新的對象。 | ? | |
| 單例模式 （Singleton?Pattern） | 保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。 | ? | |
| ? | |||
| 結構型模式 | 適配器模式 （Adapter?Pattern） | 將一個類的接口轉換成客戶希望的另外一個接口。使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。 | ? |
| 橋接模式（Bridge?Pattern） | 將抽象部分與實際部分分離，使它們都可以獨立的變化。 | ? | |
| 組合模式 （Composite?Pattern） | 將對象組合成樹形結構以表示“部分--整體”的層次結構。使得用戶對單個對象和組合對象的使用具有一致性。 | ? | |
| 裝飾者模式 （Decorator?Pattern） | 動態的給一個對象添加一些額外的職責。就增加功能來說，此模式比生成子類更為靈活。 | ? | |
| 外觀模式 （Facade?Pattern） | 為子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。 | ? | |
| 享元模式 （Flyweight?Pattern） | 以共享的方式高效的支持大量的細粒度的對象。 | ? | |
| 代理模式 （Proxy?Pattern） | 為其他對象提供一種代理以控制對這個對象的訪問。 | ? | |
| ? | |||
| 行為型模式 | 責任鏈模式 （Chain?of?Responsibility?Pattern） | 在該模式里，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求，這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。 | ? |
| 命令模式 （Command?Pattern） | 將一個請求封裝為一個對象，從而使你可用不同的請求對客戶端進行參數化；對請求排隊或記錄請求日志，以及支持可撤銷的操作。 | ? | |
| 解釋器模式 （Interpreter?Pattern） | 描述了如何為簡單的語言定義一個語法，如何在該語言中表示一個句子，以及如何解釋這些句子。 | ? | |
| 迭代器模式 （Iterator?Pattern） | 提供了一種方法順序來訪問一個聚合對象中的各個元素，而又不需要暴露該對象的內部表示。 | ? | |
| 中介者模式 （Mediator?Pattern） | 定義一個中介對象來封裝系列對象之間的交互。終結者使各個對象不需要顯示的相互調用?，從而使其耦合性松散，而且可以獨立的改變他們之間的交互。 | ? | |
| 備忘錄模式 （Memento?Pattern） | 在不破壞封裝的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。 | ? | |
| 觀察者模式 （Observer?Pattern） | 定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并被自動更新。 | ? | |
| 狀態模式（State?Pattern） | 允許一個對象在其內部狀態改變時改變它的行為，使對象看起來似乎修改了它的類。 | ? | |
| 策略模式（Strategy?Pattern） | 準備一組算法，并將每一個算法封裝起來，使得它們可以互換。 | ? | |
| 模板方法模式 （Template?Method?Pattern） ? ? ? ?? | 使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。 | ? | |
| 訪問者模式 （Visitor?Pattern） | 表示一個作用于某對象結構中的各元素的操作，它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。 | ? | |
?
二、六大設計原則:
| 六大設計原則 | 說明 | 備注 |
| SRP（單一職責原則） | 有且只有一個原因引起類的變更。 | ? |
| LSP（里氏替換原則） | 子類必須完全實現父類接口，在系統中完全可以用子類替換父類，即子類型必須能夠替換它們的基類型。 | ? |
| DIP（依賴倒轉原則） | 1. 高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象。 2. 抽象不應該依賴于實現細節，實現細節應該依賴于抽象。 | ? |
| ISP（接口隔離原則） | 不能強迫用戶去依賴那些他們不使用的接口。 | ? |
| LOD（迪米特原則） | 只和友元類交流，出現在成員變量，函數輸入輸出參數中的類，是朋友類。強調類之間的松散耦合。 | ? |
| OCP（開放-封閉原則） | 對擴展開放，對修改封閉。 | ? |
總結
以上是生活随笔為你收集整理的UML+模式设计概述的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 西部数据 SN850P PS5 授权款
- 下一篇： 浅谈我对框架的理解