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

在解決這個論題之前，我們首先要了解設計模式的概念，及其基本的分類。

「設計模式」這四個字，相信大家在很多地方都會看到，

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

由於[gof95]是論述軟體模式的著作的第一本，因此有些人常常使用設計模式（design pattern）一詞來指所有直接處理軟體的架構、設計、程式實現的任何種類的模式。

建立型設計模式，如工廠方法（factory method）模式、抽象工廠（abstract factory）模式、原型（prototype）模式、單例（singleton）模式，建造（builder）模式等

結構型設計模式，如合成（composite）模式、裝飾（decorator）模式、**（proxy）模式、享元（flyweight）模式、門面（facade）模式、橋梁（bridge）模式等

行為型模式，如模版方法（template method）模式、觀察者（observer）模式、迭代子（iterator）模式、責任鏈（chain of responsibility）模式、備忘錄（memento）模式、命令（command）模式、狀態（state）模式、訪問者（visitor）模式等等。

以上是三種經典型別，實際上還有很多其他的型別，比如fundamental型、partition型，relation型等等。

設計模式是物件導向程式設計的熱門話題之一，越來越多的開發人員認識到設計模式的重要性。採用各種語言實現設計模式的文章也越來越多，但是很多開發人員發現很難將設計模式與實際開發中需要解決的具體問題相聯絡。因為使用設計模式的難點往往不在於模式的實現，而在於很難確定哪種模式可以在現實的應用場景中採用，從而導致了在現實的專案中，面對客戶的壓力，我們總是採用最直截了當的方法解決問題，來不及多考慮這些方法的優劣，即使明知將帶來更大的麻煩也必須如此。有些時候因為選擇了不恰當的設計模式，使原本簡單的問題變得複雜化。

這裡通過先通過幾個簡單例子的說明來介紹在設計模式實際的軟體開發中的使用。然後再通過乙個專案的分析來論述軟體開發中設計模式的使用效果。

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

if (type == 1)  else if (type == 2)  else

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

public static string getproperty(string propkey) throws exception ...

該段**是我以前在乙個專案中寫的一段**，該段**用於讀取工程配置檔案的屬性，但該段**是存在一些問題的，因為在每次獲取屬性時，它都重新載入資源，造成了資源的過多損耗。

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

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

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

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

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

public inte***ce type

型別1、型別2等可以實現該介面，**略：

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

import //略
public class propertiesutil ...
//在propertiesmap中獲得propkey屬性，並將值返回（略）
}}

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

1）對於計算機的外部資源印表機的情況，因只有乙個printer spooler，為避免兩個列印作業同時輸出到印表機中，可考慮用單例模式實現。

2）window的**站在整個系統中只有唯一的乙個例項，而且**站自行提供自己的例項，**站也是單例模式的應用

下面通過我以前做過的乙個《圖書管理系統》中設計的乙個問題來詳細做闡述：

我的系統的按功能包括：登入模組，圖書借閱模組，圖書資訊查詢模組，歸還圖書模組，使用者管理模組，圖書管理模組等。

而在這些模組中又包含很多小的模組，比如：使用者管理模組又包含：新增新使用者，刪除使用者，更改使用者資訊三個子模組，類似的還有其他模組。

那我們來如何處理這種複雜的系統呢？按照我們平時的習慣:處理複雜系統的乙個常見的方法便是將其「分而治之「，把乙個系統劃分為幾個較小的子系統。但是這樣做了以後，設計者仍然會發現乙個子系統內仍然有太多的型別要處理。而使用乙個子系統的使用端往往只會關注一些特定的功能，卻要同時與子系統內容內部的許多物件打交道後才能達到目的。

借書還書

查詢借閱者

借閱者借閱者

這就是一種不便，它使得系統的邏輯變得不必要的複雜，維護成本提高，復用率降低。

模式。仍然通過醫院的範例說明，可以設定乙個接待員的位置，由接待員負責代為**、劃價、繳費、取藥等。這個接待員就是

facade

模式的體現，病人只接觸接待員，由接待員負責與醫院的各個部門打交道。

我一想，自己不傻了嗎，而對於《圖書管理系統》我可以建立乙個圖書館員來處理所有讀者對系統的要求，這樣就像醫院的接待員一樣，

facade

模式的門面型別將使用端與子系統的內部複雜性分隔開，使得使用端只需要與門面物件打交道，而不需要與子系統內部的很多物件打交道。

facade模式要求乙個子系統的外部與其內部的通訊必須通過乙個統一的門面（facade）物件進行。facade模式提供乙個高等

級的介面，使得子系統更易於使用。

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

1）可以比較好的分工(比如，使用介面型別模式)

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

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

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

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

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

MBTI在軟體開發團隊中的應用

相關推薦

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