Java設計模式和軟件工程之DesignPattern介紹

2019-11-18 12:17:34

字體：大中小

來源：轉載

供稿：網友

　　什么是Design Pattern...
　　
　　在OO Design中，reueable 是一個非常重要的組成部分。也就是說如何讓你的code能被其他的程序利用是design的要害部分！
　　
　　讓code reuseable有多種辦法，除了oo language本身的hirechay等特性外，把現實中的問題記錄下來，然后發表，可防止重復的開發過程。
　　
　　Design Pattern就是一些已被記錄的方法，并且有系統的描述。
　　
　　根據 Christopher Alexander “每個pattern描述了在特定環境下發生了很多次的問題，然后你便可以描述這些問題的共性并提供解決的辦法”
　　
　　這就好象磚頭一定是方的，這樣他便能很輕易地和其他磚頭一起被砌成房子。
　　
　　java在resuseable方面有突出的表現，如interface的引入，使很多在c++中曖昧的繼續關系得到有效的解決。應該來說，java語言的本身擁有很多OO的嫡系血統，整合了現代的編程方法。當然我們都了解有關
　　implementation的缺陷使得它的應用受到很大限制。但從design的角度說，它的確是一種非凡的東西。這也是為什么我想用它來解釋pattern的原因。
　　
　　實例1：在sun java的native lib中，我們隨處可見design pattern的身影。比如在新的event model中，Listener 便是一種叫Observer的pattern(MFC 中的notification 也是出于其中)
　　
　　實例2：JFC UI種的plugable Look & Feel 結合了Abstract Factory 和Bridge Pattern。前者能產生一組widget factory,而后者則提供了建立
　　
　　在一致interface上具體的實現方法。
　　
　　當然在實際的開發中你可能碰到各種問題，假如你能把它們系統地記錄下來并提供實際的解決辦法，這就可能是一種新的pattern。但記住pattern是能解決一類問題的方法，而不是一個問題。所以對一類問題的共性歸類很重要。在以后我們會介紹如何來做這方面的工作。
　　
　　后：
　　
　　1.小弟的中文水平差的可以，那位仁兄能幫忙指正的話，在下感激不盡。
　　
　　2.做比說重要。
　　
　　3.多謝compiler的鼓勵，希望能共同努力，把這一系列寫完
　　
　　4.這里到底是不是java group? 怎么盡是些不著邊際的post.
　　上一次我們主要介紹了什么是Design Pattern，作為一部分的補充，這次想討論一下記錄Design Pattern的格式和方法。
　　
　　雖然Design Pattern源自于Object Oriented Design的方法，但它又是完全基于實踐的。因此選擇何種語言及上下文的關系對與讀者至關重要。
　　
　　基本上每種Pattern都會有相應的UML(1)和Interactive Diagram(2),同時配以簡潔的示范代碼來表達作者在當時的想法。
　　
　　可以想象一種Pattern的應用面決定不止以某種特定的場景。打個比方，Composite Pattern這種建立于包含關系的object strUCture可以表達很多類事物，如桌面應用文件的結構，網絡中分布對象的集合等等，它并沒有局限于某類應用。
　　
　　而基于不同的實現語言，Pattern的實現也會很不一樣。我們以后會提到的Singleton在C++中的實現和Java中的實現有很大的區別。
　　
　　大致上每種Pattern都包含了一下幾個部分。
　　
　　Pattern Name: 名字
　　
　　PRoblem: 講述Pattern的來源及上下文關系。問題的種類可有很多種，有時我們可能想用objects來表達某種算法，而有時確是為了如何表達objects之間的結構。而且在一些情況下我們還要告訴讀者在碰到這個問題前，我們已經用何種方法解決了前因。
　　
　　The Solution:解決之道。包括用哪些元素來做Design，Element之間的關系，結構，調用的順序，變種等等。為了清析的表達一個Design，往往輔助以UML,Interactive Diagram,Code Sample等。因為Pattern 就象一種
　　
　　Tempelate,可以應用于不同的場合，所以Solution不應該是描述一中特定的設計。
　　
　　The Consequence:結果。這是最輕易被人忽視的一點。因為Design的需要Pattern并不往往是最有效率的方案，在一些情況下，我們犧牲很有效率的方案僅僅是為了讓別人能看懂我們的程序。(個人認為這很重要)所以我們一定要注明在那些地方我們做了妥協。并盡可能地預計所會產生的正面及負面效果。
　　
　　注：
　　
　　UML:Unified Modeling Language是解釋Objects靜態關系的一種圖表
　　
　　Interactive Diagram：描述objects之間的動態關系
　　看著自己以前寫幾篇的Design Pattern文章,越看越喜歡.
　　
　　算了, 不管有沒有人看,寫下去再說!
　　
　　上幾次主要介紹了Design Pattern的基本概念,和文檔的
　　
　　格式. Design Pattern在現實的世界中共有23種標準的
　　
　　pattern. 最早出現在由Erich Gamma, Richard Helm,
　　
　　Ralph Johnson和John Vlissides編寫的"Design Patterns"
　　
　　一書. 由于此書一成為OO Design的標準參考書之一, 所以許多專家建議在實際開發中,Developers 應該用標準的pattern來相互交流, 以便于了解彼此的設計思想. Java的標準庫便運用此原則, 對于標準Pattern的擴展, 大多也有明確的出處(如Listener便源自于Observer).
　　
　　按照不同的應用原則, 標準Pattern 分為三個類別
　　
　　1. "Creational Patterns" 主要用于創建Objects, 典型
　　
　　有Factory Pattern.
　　
　　2. "Structural Patterns" 用于組織不同的objects并整合成復雜結構, 如 Adapter, Bridge 等
　　
　　3. "Behavioral Patterns" 主要描述了object和class間交互的方法, 它可以把一個十分復雜控制流分解成不同的部分,并交由不同的object處理. 如 Observer, Command等
　　
　　下面我將標準的Pattern列出:
　　
　　==============
　　
　　Creational Patterns
　　
　　==============
　　
　　* Abstract Factory
　　
　　* Builder
　　
　　* Factory Method
　　
　　* Prototype
　　
　　* Singleton
　　
　　==============
　　
　　Structural Patterns
　　
　　==============
　　
　　* Adapter
　　
　　* Bridge
　　
　　* Composite
　　
　　* Decorator
　　
　　* Facade
　　
　　* Flyweight
　　
　　* Proxy
　　
　　==============
　　
　　Behavioral Patterns
　　
　　==============
　　
　　* Chain Of Responsibility
　　
　　* Command
　　
　　* Interpreter
　　
　　* Iterator
　　
　　* Mediator
　　
　　* Memento
　　
　　* Observer
　　
　　* State
　　
　　* Strategy
　　
　　* Template Method
　　
　　* Visitor
　　現在開始, 我將有選擇地介紹不同的Patterns
　　
　　名字:
　　
　　====
　　
　　1. Factory Method, (可能是最常用的了. )
　　
　　問題:
　　
　　====
　　
　　在一個Class繼續關系中, 在最頂層的抽象類定義了一組objects
　　
　　的關系. 每個object很可能屬于另一個抽象的繼續關系.而你
　　
　　得Classes 處于整個關系的中間層次, 你需要不同的Class包含不同產品.
　　
　　解決方法:
　　
　　=======
　　
　　參考一個簡單的實列: 在一個Model View Control的結構中,
　　
　　抽象的Controller需要有 Model 和 View的 Interface.
　　
　　Controller的子類則需要具體的 model 和 view. 這時我們就可
　　
　　以在 AbstractController中定義
　　
　　Class AbstractController {
　　
　　abstract protected Model createModel ();
　　
　　abstract protected View createView();
　　
　　}
　　
　　每個controller的子類只需要overiden這兩個method, 就可以獲得
　　
　　一個適合它的Model和View. 如在ConcreteController中
　　
　　Class ConcreteController {
　　
　　protected Model createModel(){
　　
　　return new ConcreteModel(this);
　　
　　}
　　
　　protected View createView(){
　　
　　return new ConcreteView(this);
　　
　　}
　　
　　}
　　
　　這兩個method就叫 "Factory Method"
　　
　　其它擴展:
　　
　　========
　　
　　在MVC的列子中, factory method應用于hireachy中, 我們還可以在一個單一的class中根據不同的要求創建不同的產品. 設想有一中Java的component可以象 Xwindow 一樣, 程序的 presentation 可以在本地的host上,也可以在remote host上. 這就需要有兩種Graphics來幫助component的 rendering. 一種是LocalGraphics, 一種是RemoteGraphics. 它們都是
　　
　　java.awt.Graphic的子類. 那么我們的這種非凡的component就需要overiden
　　Component中getGraphics()這個method.
　　
　　Class DistComponent extends Component
　　
　　{
　　
　　.......
　　
　　protected Graphics getGraphics() {
　　
　　if ( isRenderingRemote())
　　
　　return new RemoteGraphics();
　　
　　else
　　
　　return new LocalGraphics();
　　
　　}
　　
　　......
　　
　　}
　　
　　在此getGraphics就是Factory Method;

上一篇：在Java中應用State設計模式

下一篇：談談設計模式中的Iterator迭代器