Java軟體架構設計慨論(轉載)--設計模式和系統架構的關係
系統的架構和設計模式是怎樣的關係?請看下面的文章:
開始之初的架構設計決定著軟體產品的生死存亡。“好的開始相當於成功一半”。
開始的架構設計也是最難的,需要調研同類產品的情況以及技術特徵,瞭解當前世界上對這種產品所能提供的理論支援和技術平臺支援。再結合自己專案的特點(需要透徹的系統分析),才能逐步形成自己專案的架構藍圖。
比如要開發網站引擎系統,就從Yahoo的個人主頁生成工具 到虛擬主機商提供的網站自動生成系統,以及IBM Webphere Portal的特點和侷限 從而從架構設計角度定立自己產品的位置。
好的設計肯定需要經過反覆修改,從簡單到複雜的迴圈測試是保證設計正確的一個好辦法
由於在開始選擇了正確的方向,後來專案的實現過程也驗證了這種選擇,但在一些架構設計的細部方面,還需要對方案進行修改,屬於那種螺旋上升的方式,顯然這是通過測試第一的思想和XP工程方法來實現的。
如果我們開始的架構設計在技術平臺定位具有一定的世界先進水平,那麼,專案開發實際有一半相當於做實驗,是研發,存在相當的技術風險。
因此,一開始我們不可能將每個需求都實現,而是採取一種簡單完成架構流程的辦法,使用最簡單的需求將整個架構都簡單的完成一遍(加入人工干預),以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作),同時也可以探知技術的深淺,掌握專案中的技術難易點。這個過程完成後,我們就對設計方案做出上面的重大修改,豐富完善了設計方案。
設計模式是支撐架構的重要元件
架構設計也類似一種工作流,它是動態的,這點不象建築設計那樣,一開始就能完全確定,架構設計伴隨著整個專案的進行過程之中,有兩種具體操作保證架構設計的正確完成,那就是設計模式(靜態)和工程專案方法(RUP或XP 動態的)。
設計模式是支撐架構的一種重要元件,這與建築有很相象的地方,一個建築物建立設計需要建築架構設計,在具體施工中,有很多建築方面的規則和模式。
我們從J2EE藍圖模式分類http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE這樣一個框架軟體的架構與設計模式的關係。
架構設計是骨架,設計模式就是肉
這樣,一個比較豐富的設計方案可以交由程式設計師進一步完成了,載輔助以適當的工程方法,這樣就可保證專案的架構設計能正確快速的完成。
時刻牢記架構設計的目標
由於架構設計是在動態中完成的,因此在把握架構設計的目標上就很重要,因此在整個專案過程中,甚至每一步我們都必須牢記我們架構設計的總體目標,可以概括下面幾點:
1. 最大化的重用:這個重用包括元件重用 和設計模式使用等多個方面。
比如,我們專案中有使用者註冊和使用者許可權系統驗證,這其實是個通用課題,每個專案只是有其內容和一些細微的差別,如果我們之前有這方面成功研發經驗,可以直接重用,如果沒有,那麼我們就要進行這個子專案的研發,在研發過程中,不能僅僅看到這個專案的需求,也要以架構的概念去完成這個可以稱為元件的子專案。
2. 儘可能的簡單明瞭:我們解決問題的總方向是將複雜問題簡單化,其實這也是中介軟體或多層體系技術的根本目標。但是在具體實施設計過程中,我們可能會將簡單問題複雜化,特別是設計模式的運用上很容易範這個錯誤,因此如何儘可能的做到設計的簡單明瞭是不容易的。
我認為落實到每個類的具體實現上要真正能體現系統事物的本質特徵,因為事物的本質特徵只有一個,你的程式碼越接近它,表示你的設計就是簡單明瞭,越簡單明瞭,你的系統就越可靠。更多情況是,一個類並不能反應事物本質,需要多個類的組合協調,那麼能夠正確使用合適的設計模式就稱為重中之重。
我們看一個具備好的架構設計的系統程式碼時,基本看到的都是設計模式,寵物店(pet store)就是這樣的例子。或者可以這樣說,一個好的架構設計基本是由簡單明瞭的多個設計模式完成的。
3. 最靈活的擴充性:架構設計要具備靈活性 擴充性,這樣,使用者可以在你的架構上進行二次開發或更加具體的開發。
要具備靈活的擴充性,就要站在理論的高度去進行架構設計,比如現在工作流概念逐步流行,因為我們具體很多實踐專案中都有工作流的影子,工作流中有一個樹形結構許可權設定的概念就對很多領域比較通用。
樹形結構是組織資訊的基本形式,我們現在看到的網站或者ERP前臺都是以樹形選單來組織功能的,那麼我們在進行架構設計時,就可以將樹形結構和功能分開設計,他們之間聯絡可以通過樹形結構的節點link在一起,就象我們可以在聖誕樹的樹枝上掛各種小禮品一樣,這些小禮品就是我們要實現的各種功能。
有了這個概念,通常比較難實現的使用者級別許可權控制也有了思路,將具體使用者或組也是和樹形結構的節點link在一起,這樣就間接實現了使用者對相應功能的許可權控制,有了這樣的基本設計方案的架構無疑具備很靈活的擴充性。
開始之初的架構設計決定著軟體產品的生死存亡。“好的開始相當於成功一半”。
開始的架構設計也是最難的,需要調研同類產品的情況以及技術特徵,瞭解當前世界上對這種產品所能提供的理論支援和技術平臺支援。再結合自己專案的特點(需要透徹的系統分析),才能逐步形成自己專案的架構藍圖。
比如要開發網站引擎系統,就從Yahoo的個人主頁生成工具 到虛擬主機商提供的網站自動生成系統,以及IBM Webphere Portal的特點和侷限 從而從架構設計角度定立自己產品的位置。
好的設計肯定需要經過反覆修改,從簡單到複雜的迴圈測試是保證設計正確的一個好辦法
由於在開始選擇了正確的方向,後來專案的實現過程也驗證了這種選擇,但在一些架構設計的細部方面,還需要對方案進行修改,屬於那種螺旋上升的方式,顯然這是通過測試第一的思想和XP工程方法來實現的。
如果我們開始的架構設計在技術平臺定位具有一定的世界先進水平,那麼,專案開發實際有一半相當於做實驗,是研發,存在相當的技術風險。
因此,一開始我們不可能將每個需求都實現,而是採取一種簡單完成架構流程的辦法,使用最簡單的需求將整個架構都簡單的完成一遍(加入人工干預),以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作),同時也可以探知技術的深淺,掌握專案中的技術難易點。這個過程完成後,我們就對設計方案做出上面的重大修改,豐富完善了設計方案。
設計模式是支撐架構的重要元件
架構設計也類似一種工作流,它是動態的,這點不象建築設計那樣,一開始就能完全確定,架構設計伴隨著整個專案的進行過程之中,有兩種具體操作保證架構設計的正確完成,那就是設計模式(靜態)和工程專案方法(RUP或XP 動態的)。
設計模式是支撐架構的一種重要元件,這與建築有很相象的地方,一個建築物建立設計需要建築架構設計,在具體施工中,有很多建築方面的規則和模式。
我們從J2EE藍圖模式分類http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE這樣一個框架軟體的架構與設計模式的關係。
架構設計是骨架,設計模式就是肉
這樣,一個比較豐富的設計方案可以交由程式設計師進一步完成了,載輔助以適當的工程方法,這樣就可保證專案的架構設計能正確快速的完成。
時刻牢記架構設計的目標
由於架構設計是在動態中完成的,因此在把握架構設計的目標上就很重要,因此在整個專案過程中,甚至每一步我們都必須牢記我們架構設計的總體目標,可以概括下面幾點:
1. 最大化的重用:這個重用包括元件重用 和設計模式使用等多個方面。
比如,我們專案中有使用者註冊和使用者許可權系統驗證,這其實是個通用課題,每個專案只是有其內容和一些細微的差別,如果我們之前有這方面成功研發經驗,可以直接重用,如果沒有,那麼我們就要進行這個子專案的研發,在研發過程中,不能僅僅看到這個專案的需求,也要以架構的概念去完成這個可以稱為元件的子專案。
2. 儘可能的簡單明瞭:我們解決問題的總方向是將複雜問題簡單化,其實這也是中介軟體或多層體系技術的根本目標。但是在具體實施設計過程中,我們可能會將簡單問題複雜化,特別是設計模式的運用上很容易範這個錯誤,因此如何儘可能的做到設計的簡單明瞭是不容易的。
我認為落實到每個類的具體實現上要真正能體現系統事物的本質特徵,因為事物的本質特徵只有一個,你的程式碼越接近它,表示你的設計就是簡單明瞭,越簡單明瞭,你的系統就越可靠。更多情況是,一個類並不能反應事物本質,需要多個類的組合協調,那麼能夠正確使用合適的設計模式就稱為重中之重。
我們看一個具備好的架構設計的系統程式碼時,基本看到的都是設計模式,寵物店(pet store)就是這樣的例子。或者可以這樣說,一個好的架構設計基本是由簡單明瞭的多個設計模式完成的。
3. 最靈活的擴充性:架構設計要具備靈活性 擴充性,這樣,使用者可以在你的架構上進行二次開發或更加具體的開發。
要具備靈活的擴充性,就要站在理論的高度去進行架構設計,比如現在工作流概念逐步流行,因為我們具體很多實踐專案中都有工作流的影子,工作流中有一個樹形結構許可權設定的概念就對很多領域比較通用。
樹形結構是組織資訊的基本形式,我們現在看到的網站或者ERP前臺都是以樹形選單來組織功能的,那麼我們在進行架構設計時,就可以將樹形結構和功能分開設計,他們之間聯絡可以通過樹形結構的節點link在一起,就象我們可以在聖誕樹的樹枝上掛各種小禮品一樣,這些小禮品就是我們要實現的各種功能。
有了這個概念,通常比較難實現的使用者級別許可權控制也有了思路,將具體使用者或組也是和樹形結構的節點link在一起,這樣就間接實現了使用者對相應功能的許可權控制,有了這樣的基本設計方案的架構無疑具備很靈活的擴充性。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/21359667/viewspace-588762/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體架構設計原則和模式(上):分層架構設計架構模式
- Java 系統架構設計Java架構
- 程式設計方法論/架構設計/模式相關轉載連結彙總程式設計架構模式
- 系統架構設計師學習(二)系統架構設計師緒論架構
- 軟體架構設計模式大全 - vikipediaaaa架構設計模式
- 軟體架構設計架構
- 論軟體架構設計及應用架構
- 架構設計思想-微服務架構設計模式架構微服務設計模式
- 軟體架構, 軟體框架,設計模式的區別架構框架設計模式
- B站評論系統架構設計架構
- 架構實戰--軟體架構設計的過程架構
- PetShop的系統架構設計(一)(轉)架構
- 架構設計方法論架構
- PetShop的系統架構設計架構
- 軟體體系架構課堂測試07 –邏輯架構設計架構
- SaaS架構:多租戶系統架構設計架構
- SaaS架構:中央庫存系統架構設計架構
- 前端架構設計的方法論前端架構
- iOS應用架構談:架構設計的方法論iOS應用架構
- 系統架構設計師感想架構
- 軟體設計、架構與 UML 建模架構
- 程式設計體系結構(09):分散式系統架構程式設計分散式架構
- 閱讀《Tomcat 系統架構與設計模式》Tomcat架構設計模式
- 論軟體系統架構風格架構
- iOS應用架構談(一):架構設計的方法論iOS應用架構
- java架構師筆記:Java中的轉換器設計模式Java架構筆記設計模式
- 軟考 - 系統架構設計師(基於中介軟體的開發)架構
- 總結 - 設計模式,企業應用架構模式,架構模式設計模式應用架構
- 架構設計架構
- [技術討論]架構設計和程式碼之間的關係以及程式設計師任務安排架構程式設計師
- 系統架構設計之-任務排程系統的設計架構
- SaaS(軟體即服務)架構設計架構
- 《軟體架構設計》讀書筆記架構筆記
- 認識軟體架構:設計面面觀架構
- 軟體自動測試架構設計架構
- 設計,架構,框架之間是什麼關係?架構框架
- 關於軟體架構和業務架構的思考架構
- 通過CSS設計模式搭建自己系統的CSS架構CSS設計模式架構