設計模式之領航篇高內聚和低耦合

什麼是耦合和內聚  

        聊聊內聚和耦合,內聚和耦合不是軟件工程的專有名詞,但是在軟件工程衡量軟件的標準。但凡用到了這兩個詞,頓時就感覺了高大上。內聚發生在是單個個體,根據不同的粒度,可以是一個模塊。一個對象,一個方法。說的是獨立個體,目標很明確,只做一件事。耦合講的是關聯性和依賴性,發生在多個個體之間,從粗粒度來看發生在兩個甚至多個系統,兩個甚至多個模塊,在細粒度可以是兩個甚至以上的對象或方法。耦合的體現,甚至當其中一方改變,另一方就受到影響。

       舉現實中具體的例子更能明白:

      高內聚,低耦合:比如小霸王學習機,卡壞了可以換張卡,遊戲機壞了換個遊戲機就好了,畢竟在成本控制內,所以遊戲機和卡的耦合性低,另外卡主要是存儲遊戲內容,遊戲機是運行遊戲,所以每個個體很高的內聚性。

      高耦合,低內聚:又比如房子和我們就是一種高耦合性的關係,如果房子出問題了,那麼直接導致我們沒有休息和居家的環境。房子內包括了我們很多生活場景,洗澡,做飯,衛生間,休息等等,這麼房子的內聚性不高。

      再來看一個,由高耦合到低耦合的演變:共享單車和私有自行車的例子。共享單車的火爆不光是出行方便,在我看來就要打破了自行車和人們強耦合性關係,有了共享單車,很大部分人都會放棄買自行車的慾望,而且當單車出現問題是,我們也不用花時間去維修,填個報修,直接換一輛就好了。高內聚性的例子:單車的用途就很單一主要用途就是來騎行,而且及時是每個零部件都有自己的功能,從每個零部件都有自己的功能,也就是內聚性高。

耦合的分級

       舉例說明現實生活中的例子是爲了更好的理解耦合內聚的概念,在軟件工程中,耦合是是常見了一種形式。比如一個類,引用了另一個的方法,那麼就可以說明這個兩個類之間是耦合關係。在軟件的執行關於耦合百科上給出來更詳細的分類:耦合度從高到低:

  • (1) 內容耦合。當一個模塊直接修改或操作另一個模塊的數據時,或一個模塊不通過正常入口而轉入另一個模塊時,這樣的耦合被稱爲內容耦合。內容耦合是最高程度的耦合,應該避免使用之。

         如:產品模塊中有修改訂單,物流信息等模塊功能的邏輯,那麼這就屬於內容耦合。內容耦合在系統設計和模塊設計等設計初期就應該儘量避免,內容耦合應該很少出現。

  • (2) 公共耦合。若一組模塊都訪問同一個公共數據環境,則它們之間的耦合就稱爲公共耦合。公共的數據環境可以是全局數據結構、共享的通信區、內存的公共覆蓋區等。

         比如兩個模塊都共同訪問一個張數據表,一塊內存或者緩存數據。

  • (3) 外部耦合 。一組模塊都訪問同一全局簡單變量而不是同一全局數據結構,而且不是通過參數表傳遞該全局變量的信息,則稱之爲外部耦合。

        例:引用一個常量?

  • (4) 控制耦合 。一個模塊通過接口向另一個模塊傳遞一個控制信號,接受信號的模塊根據信號值而進行適當的動作,這種耦合被稱爲控制耦合。

        例子:這種更常見吧,根據訂單狀態來進一步確認物流信息或者根據用戶狀態判斷功能是否會可以使用。

  • (5) 標記耦合 。若一個模塊A通過接口向兩個模塊B和C傳遞一個公共參數,那麼稱模塊B和C之間存在一個標記耦合。
  • (6) 數據耦合。模塊之間通過參數來傳遞數據,那麼被稱爲數據耦合。數據耦合是最低的一種耦合形式,系統中一般都存在這種類型的耦合,因爲爲了完成一些有意義的功能,往往需要將某些模塊的輸出數據作爲另一些模塊的輸入數據。

         例子:常用的數據傳遞,比如貸款模塊經常會用到查看客戶信息數據

  • (7) 非直接耦合 。兩個模塊之間沒有直接關係,它們之間的聯繫完全是通過主模塊的控制和調用來實現的。

         現在我們可以理解怎麼分辨耦合,就是兩個有關係的對象,當一個對象修改會影響到另一個對象時,耦合度越高,那麼影響的範圍越大。而在設計開發中,耦合的邊界其實是最難定義的,只能定義相對低耦合,沒有完全的解藕,獨立的個體存在是沒有意義的。

內聚的段位

       內聚似乎感覺比耦合更容易理解,首先確定內聚就是一個方法,一個對象(類),甚至是一個模塊的內部元素緊密聯繫,而且儘量做到功能單一和屬性單一。在百科中內聚按強度從低到高有以下幾種類型:

  • (1)偶然內聚:如果一個模塊的各成分之間毫無關係,則稱爲偶然內聚,也就是說模塊完成一組任務,這些任務之間的關係鬆散,實際上沒有什麼聯繫。
  • (2)邏輯內聚:幾個邏輯上相關的功能被放在同一模塊中,則稱爲邏輯內聚。如一個模塊讀取各種不同類型外設的輸入。儘管邏輯內聚比偶然內聚合理一些,但邏輯內聚的模塊各成分在功能上並無關係,即使局部功能的修改有時也會影響全局,因此這類模塊的修改也比較困難。
  • (3)時間內聚:如果一個模塊完成的功能必須在同一時間內執行(如系統初始化),但這些功能只是因爲時間因素關聯在一起,則稱爲時間內聚。
  • (4)通信內聚:如果一個模塊的所有成分都操作同一數據集或生成同一數據集,則稱爲通信內聚。
  • (5)順序內聚:如果一個模塊的各個成分和同一個功能密切相關,而且一個成分的輸出作爲另一個成分的輸入,則稱爲順序內聚。
  • (6)功能內聚:模塊的所有成分對於完成單一的功能都是必須的,則稱爲功能內聚。 (7)信息內聚  模塊完成多個功能,各個功能都在同一數據結構上操作,每一項功能有一個唯一的入口點。這個模塊將根據不同的要求,確定該模塊執行哪一個功能。由於這個模塊的所有功能都是基於同一個數據結構(符號表),因此,它是一個信息內聚的模塊。

         內聚和耦合是兩個關聯性很強的關係,低耦合必然是要高內聚,反過來,高耦合,其實也會降低內聚性。內聚和耦合這兩個方面本身存在依賴關係。

結合實際

        結合目前項目的做的分佈式式拆分,整個系統看似已按照模塊功能劃分,但實際上由於中心思想並未真正傳達到每個coder上,而且對於設計和codeviwv做的真是有點糟糕,導致各個模塊之間耦合度很高。痛定思痛後,經過幾天幾輪研討,對模塊有又了重新的劃分,對於耦合性較高的模塊根據功能特點抽取了一個獨立的公共模塊,修改模塊的關係,對於內容耦合部分,儘量修改爲數據耦合。

        一個高內聚,低耦合的項目,模塊清晰,每個模塊都有自己獨立功能和職責,項目易於管理,代碼更加清晰而且重複利用率高。目前很多mvc框架極大的幫住了我們項目的解藕。分佈式架構體系也是從架構層面的一種解藕,架構中分出不同的節點或者說是模塊更清晰的表明職責,解決了單體應用的一損俱損的弊端。如何設計一個高內聚低耦合的項目,首先要從思想上建立一個規範思想,而在實踐中確立和實現這種思想。有人說需求是變化莫測的,業務驅動技術,技術也催生業務,相關性的共同成長。當然一個項目不可能一直是完美,這就需要不停打磨,重構再重構,才能更完善。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章