在上篇中咱們講解了幾類UML2.0語言新推出的建模圖形,整體來講經過這些圖形能更詳細的將某類信息表達出來。在這裏咱們簡單回顧上篇講解的內容。html
上圖中已經簡單介紹了上章講述的內容,具體內容請看:系統架構師-基礎到企業應用架構-系統建模[下篇]。數據庫
本章將主要的簡單介紹在系統架構中的設計模式及相應規範準則。並結合相應的代碼來講明如何遵循系統架構中的一些基本的設計規範及準則。而咱們將在本文介設計模式
紹幾類經常使用的設計規範,咱們先來看看結構化設計的二個基本原則:安全
固然既然提出了基本的準則,那麼咱們如何來知足準則呢,而且能更好的設計呢?咱們能夠經過以下手段來達到這樣的要求:性能優化
固然圖中演示了功能分離的策略,經過把需求按照不一樣的功能詳細的劃分開來,每一個功能都是獨立服務器
的,固然咱們這裏也能夠成爲是關注點。下面咱們將針對這些原則進行詳細的講解。架構
一、上章回顧。模塊化
二、摘要。函數
三、本章內容。性能
四、設計規範及原則。
五、如何知足設計要求。
六、本章總結。
七、系列進度。
八、下篇預告。
首先咱們來看看內聚的含義:軟件含義上的內聚實際上是從化學中的分子的內聚演變過來的,化學中的分子間的做用力,做用力強則表現爲內聚程度高。在軟件中內
聚程度的高低,標識着軟件設計的好壞。
咱們在進行架構設計時的內聚高低是指,設計某個模塊或者關注點時,模塊或關注點內部的一系列相關功能的相關程度的高低。
例如:下單模塊:
通常狀況下,下單模塊都會有以下的信息,訂單的信息,產品的信息及誰下的單(買家信息)。這是基
本的,那麼咱們設計的時候就要把相關的功能內聚到一塊兒。固然這是從大功能(下單管理)上來講,固然這些模塊還能夠再細化分紅產品、訂單、會員等子模塊。
例如咱們在設計數據庫操做輔助類提供的方法有:
經過這樣的方式,那麼這個組件只負責數據庫操做。這樣帶來的好處也是顯而易見的。高內
聚提供了更好的可維護性和可複用性。而低內聚的模塊則表名模塊直接的依賴程度高,那麼一旦修改了該模塊依賴的對象則沒法使用該模塊,必須也進行相應的修改才
能夠繼續使用。
低內聚的模塊設計的壞處有:首先模塊的功能不單一,模塊的職責不明確,比較鬆散,更有甚者是完成不相關的功能。這樣的設計每每是不可取的。能夠經過重
構來完善。
下面咱們來講下高內聚的簡單解釋:什麼樣的模塊算是高內聚,而且可以在系統中很好的使用。
那麼咱們在設計的過程當中如何去完成高內聚呢?
以上基本上講述了高內聚的好處,而且闡述瞭如何實現高內聚的步驟和原則。下面咱們來講說可能高內聚帶來的壞處。
高內聚有時候也不是說全部的狀況都採用這樣的原則,固然高內聚仍是要適度的,下面來舉例說明:例如內聚性要求強的話就像Windows32中系統提供的
API,裏面的函數太多了,都放在一個Dll中,那麼每一個函數完成一個功能。這樣強大的功能,會比較複雜,因此並非徹底的高內聚越高越好,仍是要看實際的須要。
固然維護起來也不是特別的方便。
首先咱們來看看低耦合的定義:低耦合是用來度量模塊與模塊直接的依賴關係。耦合固然也能夠這樣簡單的理解,我想懂電腦的應該都知道,CPU與主板之間的
關係,CPU若是是特殊的CPU必須使用特殊的主板來支持,那麼若是說這個CPU不惟一依賴惟一主板,那麼就認爲這個CPU與主板的關係是低耦合的關係。
下面咱們來舉例說明低耦合的設計與高耦合的設計:
這是一個簡單的低耦合的設計,電器與插座之間是低耦合的關係,就算我替換了不一樣的插座,電器依
然能夠正常的工做。所以簡單的描述以下,就是A模塊與B模塊存在依賴關係,那麼當B發生改變時,A模塊仍然能夠正常工做,那麼就認爲A與B是低耦合的。
一、筆記本接音響能夠正常的使用。
二、筆記本接專配耳機正常的使用。
對應通常的音響來講,筆記本是通用的,音響和筆記本直接的關係是低耦合的,可是筆記本和耳機倒是高耦合的,只有專配的耳機才能和筆記本互聯使用,而不
是通用的,因此說筆記本和專配耳機存在着較強的依賴關係。固然最簡單的方式就是筆記本提供統一的耳機接口,能夠知足通常性的需求。
下面咱們未來分析如何構建低耦合的設計。
上面咱們已經講解了低耦合和高內聚的二個原則,經過這2個原則咱們知道,知足這2個原則是衡量一個架構設計好壞的一個參考標準。下面咱們未來講解經過
功能分離的方式來知足上面的2個原則。
一、如何按功能進行模塊化的分離。
咱們在將一個系統進行功能劃分時,咱們通常以下來進行:
首先、咱們先把功能職責劃分紅獨立的單元。
例如如今有個B2C系統,那麼咱們按照B2C的需求,以下分析:
咱們這裏簡單的分析下B2C應該具備的功能模塊,固然這些模塊的劃分中,有些模
塊還能夠繼續的分離,固然我這裏只是實例分析出來。
二、對分離出來的模塊化進行抽象,例如咱們以支付爲例。
這裏經過支付接口向外提供服務。那麼外界模塊不關心支付系統模塊的變化,只須要調用接口
便可,若是具體的支付方式,好比支付寶的方式發生改變,在調用支付服務的模塊中也不須要作任何的修改就能夠正常的提供服務。顯然這樣的方式是不錯的實現方
式。
一般狀況下咱們在系統分離式只是以接口的方式提供服務,供其餘的模塊進行使用。在模塊內部有大量的信息是不要向外部暴露的,因此模塊在設計時訪問域的定
義就要劃分好,防止由於訪問域的定義而對模塊的信息形成破壞。
下面咱們來看下功能分離在不一樣的設計理念下都是什麼樣的表現:
上面只是實體性的分析了功能分離的好處及應用的廣度,固然咱們在後續會結合實例來說解如何來實現這樣的軟件設計模式。固然這只是軟件的架構設計,那麼如
果細化到具體的實現呢?咱們如何去設計每一個功能點呢?這就是下章咱們要講解的內容了,那麼本文先列出二種常見的方式。
下篇咱們將針對設計原則中的實現方式,進行詳細的剖析與具體實現進行舉例講解,但願你們多提意見。
本章中主要簡單的講述了軟件設計的二個基本的規範與原則:
一、高內聚:描述了模塊內部的一系列功能的相關程度,對於功能之間相關度不高或者根本沒有相關性的功能包含在模塊中的作法是不可取的。
二、低耦合:描述了模塊直接的依賴、感知程度,耦合的衡量標準是從低到高,通常來講耦合度越低越好。
固然有些特殊狀況下,可能這二個原則也有矛盾的地方,固然咱們仍是要根據項目的實際須要及狀況進行抉擇,固然這二個原則是爲了設計提供更好的擴展性、
可讀性、可維護性、極高的可複用性,因此要求咱們在設計時儘可能去知足這二個基本原則。而幫我去達到這二個準則的途徑就是經過功能分離及細化來實現這樣的準
則。下一篇咱們將深刻的分析與舉例來講明實現這二個原則的各類規範及準則。
六、系統架構師-基礎到企業應用架構-系統設計規範與原則[上篇]
七、系統架構師-基礎到企業應用架構-系統設計規範與原則[下篇]
八、系統架構師-基礎到企業應用架構-設計模式[上篇]
九、系統架構師-基礎到企業應用架構-設計模式[中篇]
十、系統架構師-基礎到企業應用架構-設計模式[下篇]
十一、系統架構師-基礎到企業應用架構-企業應用架構
十二、系統架構師-基礎到企業應用架構-分層[上篇]
1三、系統架構師-基礎到企業應用架構-分層[中篇]
1四、系統架構師-基礎到企業應用架構-分層[下篇]
1五、系統架構師-基礎到企業應用架構-表現層
1六、系統架構師-基礎到企業應用架構-服務層
1七、系統架構師-基礎到企業應用架構-業務邏輯層
1八、系統架構師-基礎到企業應用架構-數據訪問層
1九、系統架構師-基礎到企業應用架構-組件服務
20、系統架構師-基礎到企業應用架構-安全機制
2一、單機應用、客戶端/服務器、多服務、企業數據總線全解析
2二、系統架構師-基礎到企業應用架構-單機應用(實例及demo)
2三、系統架構師-基礎到企業應用架構-客戶端/服務器(實例及demo)
2四、系統架構師-基礎到企業應用架構-多服務(實例及demo)
2五、系統架構師-基礎到企業應用架構-企業數據總線(實例及demo)
2六、系統架構師-基礎到企業應用架構-性能優化(架構瓶頸)
2七、系統架構師-基礎到企業應用架構-完整的架構方案實例[上篇]
2八、系統架構師-基礎到企業應用架構-完整的架構方案實例[中篇]
2九、系統架構師-基礎到企業應用架構-完整的架構方案實例[下篇]
30、系統架構師-基礎到企業應用架構-總結及後續
下一篇將會已咱們將深刻的講解功能分離的設計準則及實現方式,如何在設計中使用設計模式來構建知足高內聚、低耦合的功能模塊等等。將經過實例化的方式對
每種原則及實現模式進行分析和舉例。若是你們有好的意見和建議能夠及時反饋,謝謝您的寶貴意見。
但願看完本章的朋友能夠從本篇中學到相應的軟件設計規範,懂的人能夠溫習下相應設計準則,本篇但願可以拋磚引玉,但願你們可以多提出寶貴意見。因爲是本
人平時工做中的理解與總結,不足之處再所不免,還請你們批評指出!若是您有什麼意見或建議,請多多提出!你們的支持就是個人最大動力!