本專題為 Java 軟件工程師們提供了面向 Java 的設計模式和建模方面相關的文章和教程。幫助讀者理解、學習作為專業(yè)軟件工程師必需掌握的設計模式與建模技術。
Factory Method 模式在 Javamail 中的應用
設計模式在軟件工程中占有重要地位，而 JavaMail 是 Java 平臺的一個擴展，為管理電子郵件提供了統(tǒng)一的應用編程接口。本文討論 Factory Method 設計模式在Javamail 中的應用。
在 Java 中應用設計模式 - Factory Method
在設計模式中,Factory Method也是比較簡單的一個,但應用非常廣泛，EJB,RMI,COM,CORBA,Swing中都可以看到此模式的影子，它是最重要的模式之一。在很多地方我們都會看到xxxFactory這樣命名的類,那么,什么是Factory Method,為什么要用這個模式,如何用Java語言來實現(xiàn)該模式,這就是本文想要帶給大家的內(nèi)容。
Factory 模式的優(yōu)點
最常見的構造一個 Object 的方法是通過構造函數(shù). 例: String strTemp = new String('Hello World'); 其實還有一種一種更靈活的創(chuàng)建Object 的方式---利用Factory 模式. 這是著名的'四人幫'(Gangs Of Four)的經(jīng)典之作'設計模式'[(Design Pattern) 所記載的23模式之一. 它有著構造函數(shù)不可比擬的一些優(yōu)點.
在 Java 中應用設計模式 -- Singleton
本文介紹了設計模式中 Singleton 的基本概念,對其功能和用途進行了簡單的分析,列出了通常實現(xiàn) Singleton 的幾種方法,并給出了詳細的Java 代碼。
Observer 模式在 J2EE 中的實現(xiàn)
設計模式是經(jīng)驗的文檔化。它是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。更通俗的來說，它是一個問題/解決方案對。一旦我們掌握了設計模式，就等于擁有了一支強有力的專家隊伍。它甚至能夠使面向?qū)ο蟮男率掷们叭说慕?jīng)驗找出職責明確的類和對象，從而獲得優(yōu)雅的解決方案。
State 模式在客戶端軟件中的應用
在對一個 J2EE 項目的重構、增加新功能的過程中，對客戶端 GUI 程序，我們使用了 State 模式。結果顯示，該模式的使用，不但減少了客戶端 GUI 程序的程序規(guī)模（LOC），而且，該部分的開發(fā)及單元測試時間大大減少，同時，在集成測試中發(fā)現(xiàn)的缺陷數(shù)量比使用該模式前平均減少了3倍。本文就該項目中使用 State 模式的方式進行介紹。
在方法簽名中使用控制反轉(zhuǎn)（IoC）
控制反轉(zhuǎn)（IoC）模式通常用于組件。本文描述了如何對方法簽名使用該模式，以減少組件間的耦合并改善性能。IBM Global Business Services 顧問 Andr Fachat 用兩個例子展示了這種方法的靈活性。
Single Call 模式
在本文中，作者向大家講述了 Single Call 模式的原理，同時也介紹了 Single Call 模式的實現(xiàn)問題。
Java 設計模式 201：超越四人組
您可以在本教程中發(fā)現(xiàn)，到底還有多少設計模式您不知道。首先，我們會探討一些資源，學習設計模式的新手通常會忽略它們。這些資源為各種計算領域（如商業(yè)應用程序、Web 應用程序，甚至 Web 設計）提供了極為有用的模式。
界面組裝器模式
本文提出了一種界面設計中的架構模式－界面組裝器模式，它致力于分解界面，將界面和組裝行為解耦，將界面邏輯處理與領域邏輯處理解耦，這樣我們在開發(fā) GUI 胖客戶端界面應用時可以從眾多的界面控制管理中解脫出來，而專注于我們的后臺業(yè)務邏輯的開發(fā)。通過該模式，我們可以動態(tài)地組裝我們的界面，我們甚至還可以在我們的界面中輕松地插入 transaction 事務或 session 會話管理。
數(shù)據(jù)校驗器架構模式組
本文闡述軟件架構與設計模式，它為架構師和開發(fā)人員提供了一組關于數(shù)據(jù)校驗的架構模式（隔離校驗器，可組裝校驗器，動態(tài)策略校驗器，動態(tài)注冊校驗器等），數(shù)據(jù)校驗是任何類型的開發(fā)中都不可或缺的環(huán)節(jié)，如果沒有統(tǒng)一的架構，可能校驗代碼會遍布整個應用，如何將數(shù)據(jù)校驗與應用邏輯解耦，如何適應各種粒度的數(shù)據(jù)和各種復雜程度業(yè)務規(guī)則，正是本文要探討的。
反模式可以如何提高編程
設計模式對軟件開發(fā)來說很重要，這一點從它在技術貿(mào)易新聞中所占的數(shù)量就可見一斑。不過，鑒于其在開發(fā)過程中的實用性，設計模式只解決了問題的一半。反模式 ― 描述“對產(chǎn)生絕對負面結果的問題的一種常用解決方案” ― 旨在通過向 Java 程序員展示如何避免常見的 Java 陷阱來解決問題的另一半。
從 Java 類庫看設計模式，第一部分
在這一部分的內(nèi)容中，介紹的是一個相對簡單但功能強大的模式：Observer 模式。希望通過這部分地敘述，大家看了之后，能夠?qū)υO計模式有一個比較全面地，感性的認識。
從 Java 類庫看設計模式，第二部分
這部分及以后的內(nèi)容，將會步入正題，從 Java 類庫的分析入手，來闡敘設計模式是如何應用到一個完美的設計中的。實際上，Java 類庫非常的龐雜，這兒不可能把所有能夠找到的設計模式的例子一一列舉，只是找了一些容易發(fā)現(xiàn)的例子。實際上也沒有必要，因為只要對一個設計模式有足夠的理解，對于它的具體應用而言，倒是一件不是很困難的事情。
從 Java 類庫看設計模式，第三部分
主要介紹幾個結構型的模式如 Bridge 模式和 Decorator 模式。對于 Bridge 模式可能需要更多的理解，因為它在很大程度上說，例示了設計模式的基本的設計思路和原則。
從 Java 類庫看設計模式，第四部分
在上一部分中，介紹了兩個結構型的模式：Bridge和Decorator。這一部分的內(nèi)容，將會接著上面的講解，繼續(xù)我們的設計模式之旅。
從 Java 類庫看設計模式，第五部分
有了前面諸多設計模式的基礎，這兒可以提出一個比較特殊的模式 MVC。MVC并不屬于 GOF 的 23 個設計模式之列，但是它在 GOF 的書中作為一個重要的例子被提出來，并給予了很高的評價。一般的來講，我們認為GOF的23個模式是一些中級的模式，在它下面還可以抽象出一些更為一般的低層的模式，在其上也可以通過組合來得到一些高級的模式。MVC就可以看作是一些模式進行組合之后的結果（實際上，MVC的出現(xiàn)要早于設計模式的提出，這而只是對它在設計模式的基礎上進行在分析）。如果沒有前面的基礎，理解MVC或許會有一些困難。
使用設計模式改善程序結構（一）
設計模式是對特定問題經(jīng)過無數(shù)次經(jīng)驗總結后提出的能夠解決它的優(yōu)雅的方案。但是，如果想要真正使設計模式發(fā)揮最大作用，僅僅知道設計模式是什么，以及它是如何實現(xiàn)的是很不夠的，因為那樣就不能使你對于設計模式有真正的理解，也就不能夠在自己的設計中正確、恰當?shù)氖褂迷O計模式。本文試圖從另一個角度（設計模式的意圖、動機）來看待設計模式，通過這種新的思路，設計模式會變得非常貼近你的設計過程，并且能夠指導、簡化你的設計，最終將會導出一個優(yōu)秀的解決方案。
使用設計模式改善程序結構（二）
在本系列的第一篇文章中，描述了如何通過設計模式來指導我們的程序重構過程，并且著重介紹了設計模式意圖、動機的重要性。在本文中我們將繼續(xù)上篇文章進行討論，這次主要著重于設計模式的適用性，對于設計模式適用性的掌握有助于從另一個不同的方面來判斷一個設計模式是否真正適用于我們的實際問題，從而做出明智的選擇。
使用設計模式改善程序結構（三）
設計模式在某種程度上確實能夠改善我們的程序結構，使設計具有更好的彈性。也正是由于這個原因，會導致我們可能過度的使用它。程序結構具有過度的、不必要的靈活性和程序結構沒有靈活性一樣都是有害的
本專題為 Java 軟件工程師們提供了面向 Java 的設計模式和建模方面相關的文章和教程。幫助讀者理解、學習作為專業(yè)軟件工程師必需掌握的設計模式與建模技術。
Factory Method 模式在 Javamail 中的應用
設計模式在軟件工程中占有重要地位，而 JavaMail 是 Java 平臺的一個擴展，為管理電子郵件提供了統(tǒng)一的應用編程接口。本文討論 Factory Method 設計模式在Javamail 中的應用。
在 Java 中應用設計模式 - Factory Method
在設計模式中,Factory Method也是比較簡單的一個,但應用非常廣泛，EJB,RMI,COM,CORBA,Swing中都可以看到此模式的影子，它是最重要的模式之一。在很多地方我們都會看到xxxFactory這樣命名的類,那么,什么是Factory Method,為什么要用這個模式,如何用Java語言來實現(xiàn)該模式,這就是本文想要帶給大家的內(nèi)容。
Factory 模式的優(yōu)點
最常見的構造一個 Object 的方法是通過構造函數(shù). 例: String strTemp = new String('Hello World'); 其實還有一種一種更靈活的創(chuàng)建Object 的方式---利用Factory 模式. 這是著名的'四人幫'(Gangs Of Four)的經(jīng)典之作'設計模式'[(Design Pattern) 所記載的23模式之一. 它有著構造函數(shù)不可比擬的一些優(yōu)點.
在 Java 中應用設計模式 -- Singleton
本文介紹了設計模式中 Singleton 的基本概念,對其功能和用途進行了簡單的分析,列出了通常實現(xiàn) Singleton 的幾種方法,并給出了詳細的Java 代碼。
Observer 模式在 J2EE 中的實現(xiàn)
設計模式是經(jīng)驗的文檔化。它是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。更通俗的來說，它是一個問題/解決方案對。一旦我們掌握了設計模式，就等于擁有了一支強有力的專家隊伍。它甚至能夠使面向?qū)ο蟮男率掷们叭说慕?jīng)驗找出職責明確的類和對象，從而獲得優(yōu)雅的解決方案。
State 模式在客戶端軟件中的應用
在對一個 J2EE 項目的重構、增加新功能的過程中，對客戶端 GUI 程序，我們使用了 State 模式。結果顯示，該模式的使用，不但減少了客戶端 GUI 程序的程序規(guī)模（LOC），而且，該部分的開發(fā)及單元測試時間大大減少，同時，在集成測試中發(fā)現(xiàn)的缺陷數(shù)量比使用該模式前平均減少了3倍。本文就該項目中使用 State 模式的方式進行介紹。
在方法簽名中使用控制反轉(zhuǎn)（IoC）
控制反轉(zhuǎn)（IoC）模式通常用于組件。本文描述了如何對方法簽名使用該模式，以減少組件間的耦合并改善性能。IBM Global Business Services 顧問 Andr Fachat 用兩個例子展示了這種方法的靈活性。
Single Call 模式
在本文中，作者向大家講述了 Single Call 模式的原理，同時也介紹了 Single Call 模式的實現(xiàn)問題。
Java 設計模式 201：超越四人組
您可以在本教程中發(fā)現(xiàn)，到底還有多少設計模式您不知道。首先，我們會探討一些資源，學習設計模式的新手通常會忽略它們。這些資源為各種計算領域（如商業(yè)應用程序、Web 應用程序，甚至 Web 設計）提供了極為有用的模式。
界面組裝器模式
本文提出了一種界面設計中的架構模式－界面組裝器模式，它致力于分解界面，將界面和組裝行為解耦，將界面邏輯處理與領域邏輯處理解耦，這樣我們在開發(fā) GUI 胖客戶端界面應用時可以從眾多的界面控制管理中解脫出來，而專注于我們的后臺業(yè)務邏輯的開發(fā)。通過該模式，我們可以動態(tài)地組裝我們的界面，我們甚至還可以在我們的界面中輕松地插入 transaction 事務或 session 會話管理。
數(shù)據(jù)校驗器架構模式組
本文闡述軟件架構與設計模式，它為架構師和開發(fā)人員提供了一組關于數(shù)據(jù)校驗的架構模式（隔離校驗器，可組裝校驗器，動態(tài)策略校驗器，動態(tài)注冊校驗器等），數(shù)據(jù)校驗是任何類型的開發(fā)中都不可或缺的環(huán)節(jié)，如果沒有統(tǒng)一的架構，可能校驗代碼會遍布整個應用，如何將數(shù)據(jù)校驗與應用邏輯解耦，如何適應各種粒度的數(shù)據(jù)和各種復雜程度業(yè)務規(guī)則，正是本文要探討的。
反模式可以如何提高編程
設計模式對軟件開發(fā)來說很重要，這一點從它在技術貿(mào)易新聞中所占的數(shù)量就可見一斑。不過，鑒于其在開發(fā)過程中的實用性，設計模式只解決了問題的一半。反模式 ― 描述“對產(chǎn)生絕對負面結果的問題的一種常用解決方案” ― 旨在通過向 Java 程序員展示如何避免常見的 Java 陷阱來解決問題的另一半。
從 Java 類庫看設計模式，第一部分
在這一部分的內(nèi)容中，介紹的是一個相對簡單但功能強大的模式：Observer 模式。希望通過這部分地敘述，大家看了之后，能夠?qū)υO計模式有一個比較全面地，感性的認識。
從 Java 類庫看設計模式，第二部分
這部分及以后的內(nèi)容，將會步入正題，從 Java 類庫的分析入手，來闡敘設計模式是如何應用到一個完美的設計中的。實際上，Java 類庫非常的龐雜，這兒不可能把所有能夠找到的設計模式的例子一一列舉，只是找了一些容易發(fā)現(xiàn)的例子。實際上也沒有必要，因為只要對一個設計模式有足夠的理解，對于它的具體應用而言，倒是一件不是很困難的事情。
從 Java 類庫看設計模式，第三部分
主要介紹幾個結構型的模式如 Bridge 模式和 Decorator 模式。對于 Bridge 模式可能需要更多的理解，因為它在很大程度上說，例示了設計模式的基本的設計思路和原則。
從 Java 類庫看設計模式，第四部分
在上一部分中，介紹了兩個結構型的模式：Bridge和Decorator。這一部分的內(nèi)容，將會接著上面的講解，繼續(xù)我們的設計模式之旅。
從 Java 類庫看設計模式，第五部分
有了前面諸多設計模式的基礎，這兒可以提出一個比較特殊的模式 MVC。MVC并不屬于 GOF 的 23 個設計模式之列，但是它在 GOF 的書中作為一個重要的例子被提出來，并給予了很高的評價。一般的來講，我們認為GOF的23個模式是一些中級的模式，在它下面還可以抽象出一些更為一般的低層的模式，在其上也可以通過組合來得到一些高級的模式。MVC就可以看作是一些模式進行組合之后的結果（實際上，MVC的出現(xiàn)要早于設計模式的提出，這而只是對它在設計模式的基礎上進行在分析）。如果沒有前面的基礎，理解MVC或許會有一些困難。
使用設計模式改善程序結構（一）
設計模式是對特定問題經(jīng)過無數(shù)次經(jīng)驗總結后提出的能夠解決它的優(yōu)雅的方案。但是，如果想要真正使設計模式發(fā)揮最大作用，僅僅知道設計模式是什么，以及它是如何實現(xiàn)的是很不夠的，因為那樣就不能使你對于設計模式有真正的理解，也就不能夠在自己的設計中正確、恰當?shù)氖褂迷O計模式。本文試圖從另一個角度（設計模式的意圖、動機）來看待設計模式，通過這種新的思路，設計模式會變得非常貼近你的設計過程，并且能夠指導、簡化你的設計，最終將會導出一個優(yōu)秀的解決方案。
使用設計模式改善程序結構（二）
在本系列的第一篇文章中，描述了如何通過設計模式來指導我們的程序重構過程，并且著重介紹了設計模式意圖、動機的重要性。在本文中我們將繼續(xù)上篇文章進行討論，這次主要著重于設計模式的適用性，對于設計模式適用性的掌握有助于從另一個不同的方面來判斷一個設計模式是否真正適用于我們的實際問題，從而做出明智的選擇。
使用設計模式改善程序結構（三）
設計模式在某種程度上確實能夠改善我們的程序結構，使設計具有更好的彈性。也正是由于這個原因，會導致我們可能過度的使用它。程序結構具有過度的、不必要的靈活性和程序結構沒有靈活性一樣都是有害的