使用設計模式改善程序結構（1）

2019-11-18 13:44:05

字體：大中小

來源：轉載

供稿：網友

　　使用設計模式改善程序結構（1）

設計模式是對特定問題經過無數次經驗總結后提出的能夠解決它的優雅的方案。但是，假如想要真正使設計模式發揮最大作用，僅僅知道設計模式是什么，以及它是如何實現的是很不夠的，因為那樣就不能使你對于設計模式有真正的理解，也就不能夠在自己的設計中正確、恰當的使用設計模式。本文試圖從另一個角度（設計模式的意圖、動機）來看待設計模式，通過這種新的思路，設計模式會變得非常貼近你的設計過程，并且能夠指導、簡化你的設計，最終將會導出一個優秀的解決方案。

1、介紹

在進行項目的開發活動中，有一些設計在項目剛剛開始工作的很好，但是隨著項目的進展，發現需要對已有的代碼進行修改或者擴展，導致這樣做的原因主要有：新的功能需求的需要以及對系統進一步理解。在這個時候，我們往往會發現進行這項工作比較困難，即使能完成也要付出很大的代價。此時，一個必須要做的工作就是要對現有的代碼進行重構（refactoring），通過重構使得我們接下來的工作變得相對輕易。

重構就是在不改變軟件系統代碼的外部行為的前提下，改善它的內部結構。重構的目標就是使代碼結構更加合理，富有彈性，能夠適應新的需求、新的變化。對于特定問題給出美麗解決方案的設計模式往往會成為重構的目標，而且一旦我們能夠識別出能夠解決我們問題的設計模式，將會大大簡化我們的工作，因為我們可以重用別人已經做過的工作。但是在我們的原始設計和最終可能會適用于我們的設計模式間的過渡并不是平滑的，而是有一個間隙。這樣的結果就是：即使我們已經知道了很多的設計模式，面對我們的實際問題，我們也沒有一個有效的方法去判定哪一個設計模式適用于我們的系統，我們應該去怎樣應用它。

造成上述問題的原因往往是由于過于注重設計模式所給出的解決方案這個結果，而對于設計模式的意圖，以及它產生的動機卻忽略了。然而，正是設計模式的意圖、動機促使人們給出了一個解決一類問題的方案這個結果，設計模式的動機、意圖體現了該模式的形成思路，所以更加貼近我們的實際問題，從而會有效的指導我們的重構歷程。本文將通過一個實例來展示這個過程。

在本文中對例子進行了簡化，這樣做是為了突出問題的實質并且會使我們的思路更加清楚。思路本身才是最重要、最根本的，簡化了的例子不會降低我們所展示的思路、方法的適用性。

2、問題描述

一個完善的軟件系統，必須要對出現的錯誤進行相應的處理，只有這樣才能使系統足夠的健壯，我預備以軟件系統中對于錯誤的處理為例，來展示我所使用的思路、方法。

在一個分布式的網管系統中，一個操作往往不會一定成功，經常會因為這樣或者那樣的原因失敗，此時我們就要根據失敗的原因相應的處理，使錯誤的影響局限在最小的范圍內，最好能夠恢復而不影響系統的正常運行，還有一點很重要，那就是在對錯誤進行處理的同時，一定不要忘記通知系統的治理者，因為只有治理者才有能力對錯誤進行進一步的分析，從而查找出錯誤的根源，從根本上解決錯誤。

下面我就從錯誤處理的通告治理者部分入手，開始我們的旅程。假定一個在一個分布式環境中訪問數據庫的操作，那么就有可能因為通信的原因或者數據庫本身的原因失敗，此時我們要通過用戶界面來通知治理者發生的錯誤。簡化了的代碼示例如下：

/* 錯誤碼定義 */
class ErrorConstant
{
public static final int ERROR_DB access = 100;
public static final int ERROR_COMMUNICATION = 101;
}

/* 省略了用戶界面中的其他的功能 */
class GUISys
{
public void announceError(int errCode) {

switch(errCode) {

case ErrorConstant.ERROR_DBACCESS:
/* 通告治理者數據庫訪問錯誤的發生*/
break;

case ErrorConstant.ERROR_COMMUNICATION:
/* 通告治理者通信錯誤的發生*/
break;

}
}
}

開始，這段代碼工作的很好，能夠完成我們需要的功能。但是這段代碼缺少相應的彈性，很難適應需求的變化。
（未完待續）

上一篇：Eclipse插件管理小結

下一篇：使用設計模式改善程序結構（三）