設計模式在軟件開發中的應用

首先了解設計模式的概念，及其基本的分類。

什麼是設計模式呢? 一個設計模式提供一種提煉子系統或軟件系統中的組件的，或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的組件中重複出現的結構，這種結構解決在一定的背景中的具有一般性的設計問題。

設計模式常常劃分成不同的種類，常見的種類有：

[color=red]創建型設計模式[/color]，如工廠方法（Factory Method）模式、抽象工廠（Abstract Factory）模式、原型（Prototype）模式、單例（Singleton）模式，建造（Builder）模式等

[color=red]結構型設計模式[/color]，如合成（Composite）模式、裝飾（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、門面（Facade）模式、橋樑（Bridge）模式等

[color=red]行爲型模式[/color]，如模版方法（Template Method）模式、觀察者（Observer）模式、迭代子（Iterator）模式、責任鏈（Chain of Responsibility）模式、備忘錄（Memento）模式、命令（Command）模式、狀態（State）模式、訪問者（Visitor）模式等等。

以上是三種經典類型，實際上還有很多其他的類型，比如Fundamental型、Partition型，Relation型等等。

先通過幾個簡單例子的說明來介紹在設計模式實際的軟件開發中的使用。

讓我們來看幾段常見但又不夠優雅的代碼，這些代碼 “你”、“我”、“他”或許都曾寫過，但是終有一天你也會與我一樣，看着有想撞牆的感覺（如果你寫了N久這樣的代碼，還沒有這種感覺，八成你是對編程不再感興趣了，你對其已經麻木）：

[color=red]1.過多的if…else判斷[/color]

if (type == 1) {
//調用獲取信息方法1
} else if (type == 2) {
//調用獲取信息方法2
…….
} else {
//調用獲取信息方法7
}

這是我們在編程或者看書中要遇到的一段代碼，如果條件判斷非常之長，並且其他有些地方也有根據類型來做不同處理的情況。這些代碼對於後階段的維護簡直是一場噩夢。

[color=red]2.多次載入資源（例如配置文件的讀取），引起資源損耗[/color]

public static String getProperty(String propKey) throws Exception ...{

Properties prop = new Properties();

InputStream propConfFile = Util.class.getClassLoader()

.getResourceAsStream("configure.properties");

//載入propConfFile到prop中，從prop中獲取propKey的值，並將其返回

}

該段代碼是我以前在一個項目中寫的一段代碼，該段代碼用於讀取工程配置文件的屬性，但該段代碼是存在一些問題的，因爲在每次獲取屬性時，它都重新載入資源，造成了資源的過多損耗。

在我編碼的過程中，遇到的問題還有很多。不夠優雅的代碼、過於僵硬的設計，等等，下面我將通過如上兩個例子討論-----

[color=red]
1. 解決過多的if…else判斷問題[/color]

如果在一段代碼中，不少地方需根據某類型或狀態等做出不同的處理，那當類型或狀態增加時，這些代碼將會過於僵硬，擴展性差，只有在各個分佈了if…else的再增加一個else if，可維護性可想而知。設計模式中有一種模式可以解決該問題，即狀態模式。狀態模式給我們帶來的好處如下：

1） 狀態模式需要對每一個對每一個系統可能取得的狀態創立一個狀態類（State）的子類，當系統的狀態變化時，系統改變所選的子類。與一個特定的狀態有關的行爲都被包裝在一個特定的對象裏，而且當需要增加新的狀態時，可以以子類的方式將它加到系統裏，從而提高了易維護性和可擴展性；

2）由於每一個狀態都被包裝到了類裏面，避免了使用過多的條件轉移語句。

下面我們對該例進行演示性的改進。我們可以定義一個類型接口，該類相當於狀態模式中的狀態類。

public interface Type {

public Object getInfo();

public Object getResult();

}

類型1、類型2等可以實現該接口，代碼略：

[color=red]
2. 解決過度資源損耗問題[/color]

在該例中，每次通過getProperty(…)方法獲取某屬性時，都會重新載入文件中的所有內容，造成資源的不必要損耗。該設計模式中，對於此種情況，可以通過單例（Singleton）模式來優化處理。

import //略

public class PropertiesUtil ...{

private static Map propertiesMap = null;

public static String getProperty(String propKey) throws Exception ...{
if (propertiesMap == null) ...{
//當propertiesMap爲空時，載入文件，將其鍵值對放入propertiesMap中(略)
}
//在propertiesMap中獲得propKey屬性，並將值返回（略）
}

}

可以考慮實現單例模式的地方還有很多，例如：

1）對於計算機的外部資源打印機的情況，因只有一個Printer Spooler，爲避免兩個打印作業同時輸出到打印機中，可考慮用單例模式實現。

2）Window的回收站在整個系統中只有唯一的一個實例，而且回收站自行提供自己的實例，回收站也是單例模式的應用

總結：

在使用了設計模式後，明顯的發現以下幾點::

1） 可以比較好的分工(比如，使用接口類型模式)

2） 代碼組織更有條理(b比如buiilder模式：像查詢的結果，中間的產生過程是非常複雜的，如果不用builder模式，誰去改了，也許過段時間，他自己都忘記了)

但是：[color=red]千萬不能爲了模式而模式。重要的是各種模式中的思想，當你理解了思想之後，在實際的開發中不用想着硬套，自己就會想到使用（就算你已經忘記它是什麼模式）。[/color]


原文網址：[url]http://blog.csdn.net/yinyuan1987/archive/2008/11/03/3209783.aspx[/url]