高內聚低耦合的分析

低耦合


耦合就是元素與元素之間的連接,感知和依賴量度。這裏說的元素即是功能,對象,系統,子系統。模塊。

例如:現在有方法A和方法B

我們在A元素去調用B元素,當B元素有問題或者不存在的時候,A元素就不能正常的工作,那麼就說元素A和元素B耦合

耦合帶來的問題:


當元素B變更或者不存在時,都將影響元素A的正常運作,影響系統的可維護性和易變更性。同時元素A只能運行在元素B中,這也大大的降低了A元素的可複用性。正因爲耦合的種種弊端,我們才需要在軟件設計上追求低耦合

低耦合如何做:


元素A不能過度依賴元素B

合理的職責劃分:讓系統中的對象各司其職,不僅是提高內聚的要求,同時也可以有效地降低耦合

使用接口而不是繼承:我們不難發現。繼承就是一種耦合,假如子類A繼承了父類B,不論是直接繼承或者間接繼承,一但父類B不存在或者發生任何變更,都將導致子類A不得不修改或者重寫。假如父類B的子類數十上百的,這就是災難性的變更。

高內聚:


高內聚是另外一個評判軟件設計質量的標準。內聚更爲專業的說法叫做功能內聚,是對系統中元素職責的相關性和集中度的量度。如果元素有高度的相關職責,除了這些職責在沒有其他的工作,那麼該元素就有高內聚。

例如:

這就好像,如果我是一個項目經理,我的職責是監控和協調我的項目各個階段的工作。當我的項目進入需求分析階段,我會請求需求分析員來完成;當我的項目進入開發階段,我會請求軟件開發人員來完成;當我的項目需要測試的時候,我會請求測試人員。。。。。。如果我參與了開發,我就不是一個高內聚的元素,因爲開發不是我的職責。

爲什麼要高內聚:


可讀性

複用性

可維護性和易變更性

簡單的理解高內聚低耦合:


耦合和內聚的的評判標準是強度,耦合越弱越好,內聚越強越好

耦合指模塊與模塊之間的關係,最弱的耦合就是通過一個主控模快來協調n哥模塊進行運作。例如:。還是舉一個我舉過的例子:客戶要求在界面上增加一個字段,你的項目要修改幾個地方呢?如果你只要修改項目文檔,那麼你的開發構架就是最低強度的耦合,而這種設計 成熟的開發團隊都已經做到了,他們使用開發工具通過項目模型驅動數據庫和各層次的代碼,而不是直接修改那些代碼;

內聚指的是模塊內部的功能,最強的就是功能不能拆分,也就是原子化。


在簡單的說:


 高內聚、低耦合講的是程序單位協作的問題,  你可以這樣理解,一個企業的管理,  最理想的情況就是各個部門各司其職,井然有序,互不干涉,  但是需要溝通交流的時候呢,  各個部門都可以找到接口人專門負責部門溝通以及對外溝通。 在軟件裏呢, 就是說各個模塊要智能明確, 一個功能儘量由一個模塊實現,  同樣,一個模塊最好只實行一個功能。這個是所謂的“內聚”;  模塊與模塊之間、系統與系統之間的交互,是不可避免的, 但是我們要儘量減少由於交互引起的單個模塊無法獨立使用或者無法移植的情況發生,  儘可能多的單獨提供接口用於對外操作, 這個就是所謂的“低耦合”。 但是實際的設計開發過程中,總會發生這樣那樣的問題與情況, 真正做到高內聚、低耦合是很難的,很多時候未必一定要這樣, 更多的時候“最適合”的纔是最好的, 不過,理解思想,審時度勢地使用, 融會貫通,靈活運用,纔是設計的王道。
————————————————
原文鏈接:https://blog.csdn.net/fangkang7/article/details/82684819

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