鬆耦合發展是什麼意思?

鬆耦合的簡介

最近，人們越來越熱衷於比較應用程序交互的鬆耦合方法和緊耦合方法。造成這個趨勢的主要技術原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、發現和集成)等標準，Web服務可以動態地發現和綁定到其他服務。而主要業務原因是：企業越來越需要靈活地處理業務流程的更改以及與合作伙伴的交互方式。鬆耦合系統的優點在於更新一個模塊不會引起其它模塊的改變。　　傳統上，業務流程是在企業範圍，甚至在企業的不同業務單元內開發。這些活動在詳細的實時信息的幫助下進行管理。跨多個業務單元或跨企業的流程必須更加靈活，以應對各種各樣的需求。在這種情況下，可能出現更多的不確定性：參與者及其角色不斷變化，所需的交互類型也不斷變化。在運營狀況起伏不定的環境下，必須有一個鬆耦合架構，以降低整體複雜性和依賴性。鬆耦合使應用程序環境更敏捷，能更快地適應更改，並且降低了風險。除此之外，系統維護也更方便。在B2B領域，由於要求業務實體之間獨立交互，因此鬆耦合顯得尤為重要。業務合作伙伴之間的關係變化莫測，聯合關係時而建立，時而又斷絕，還需要在商業合作伙伴之間建立業務流程以滿足市場的要求。兩家公司在某一市場是合作伙伴，而在另一市場卻可能是競爭對手。底層IT基礎結構要適應這樣的靈活性和獨立性要求。理想情況下，業務關係應當互不影響：在建立新型業務關係時，不對已有的業務關係造成影響。為一個業務合作伙伴提供的功能或許不應當供給另一個合作伙伴；與一個業務合作伙伴相關的更改不應對其他合作伙伴造成影響。一個商業合作伙伴不應為了等待一個同步響應，而阻塞另一個合作伙伴。IT系統的可用性也不應依賴於業務合作伙伴IT系統的技術可用性。

鬆耦合是什麼意思

鬆耦合系統通常是基於消息的系統，此時客戶端和遠程服務並不知道對方是如何實現的。客戶端和服務之間的通訊由消息的架構支配。只要消息符合協商的架構，則客戶端或服務的實現就可以根據需要進行更改，而不必擔心會破壞對方。鬆耦合通訊機制提供了緊耦合機制所沒有的許多優點，並且它們有助於降低客戶端和遠程服務之間的依賴性。但是，緊耦合性通常可以提供性能好處，便於在客戶端和服務之間進行更為緊密的集成

Synchroflow

SynchroFLOW4.0變身“立體工作流” （1）

發佈時間：2006.09.11 14:33 來源：賽迪網 作者：馬燦東

1. 引言

隨著我國信息化程度的不斷提高，工作流技術在各個行業的信息系統中都得到了廣泛的應用。基於工作流技術發展而來的工作流管理系統也越來越成為一種重要的基礎中間件軟件產品。電子政務、電信、物流等各種行業領域，都在基於工作流平臺之上開發其各自領域的應用系統。這些基於工作流的應用系統，為各自領域的企事業單位進行流程自動化、流程再造等發揮了重要作用。

但隨著信息化的不斷深入，工作流應用的行業領域的不斷增加，工作流管理系統被用來描述越來越多、越來越複雜的各種業務流程，對工作流平臺產品提出了更高的要求。要求工作流平臺能夠提供更強大、更方便的模型表達能力，來適應業務的複雜性，適應業務的不斷髮展變化。

西安協同時光軟件有限公司的工作流管理系統SynchroFLOW®4.0在對基於Petri網的工作流模型擴展的基礎上提出了立體工作流的概念，由一個“平面”。的工作流系統，變身為“立體工作流”。立體工作流就是通過AOP技術，來捕獲工作流事件，通過為工作流事件編寫各種動作腳本，大大提高了模型表達能力。

2. 工作流的發展趨勢

自1993年工作流管理聯盟（WfMC）的成立標誌著工作流技術開始進入相對成熟的階段。十幾年來，工作流理論獲得了快速發展，各種工作流產品也不斷湧現。工作流技術在幾乎各種行業中都得到了大量應用。

隨著應用的深入，工作流產品體現出如下的現狀和特點：

（1）工作流要描述的流程越來越複雜

佩特里教授根據Petri網原理研究了21種工作流模式，包括5個基本模式、5個高級分支與同步模式、2個結構模式、4個多實例模式、3個基於狀態的模式、2個取消模式。隨著這些工作流模式的出現，對複雜的工作流模型有了很好的表達能力，基本可以解決現實生活中遇到的大部分業務流程。但現在的工作流產品大部分依然存在著這些模式實現複雜、過程繁瑣、甚至間接實現的問題。客戶在應用工作流產品時依然要編寫大量的代碼，這大大降低了開發效率。

（2）工作流產品逐漸呈現平臺化發展趨勢

現在市場上的工作流產品不僅僅只是一個工作流引擎，而是提供一個整體的開發平臺，包括表單設計工具、應用部署工具、組織機構建模工具、流程遷移工具、管理監控工具等一整套開發工具。那些僅提供工作流引擎的產品已經不能適應開發者的需要。

工作流平臺化的趨勢，代表了客戶要求降低總體擁有成本，也就是工作流平臺不僅要提供流程引擎功能，也要提供流程相關的外圍工具功能。通過這樣一個工作流平臺就完成應用系統開發的大部分工作。這樣節約開發時間，降低維護的成本。

（3）工作流產品要適應現在的應用系統輕量化、鬆耦合的發展趨勢

隨著輕量化的框架技術，比如struts、hibernate、spring等的出現並大量流行，輕量化已經成為應用系統開發的新趨勢。輕量化就是各個應用系統之間、應用系統的各個模塊之間要簡單化、鬆耦合。模塊的相互依賴性降低，各個模塊相對獨立。模塊與模塊之間的關聯，通過標準的規範或者XML等進行連接。

為了適應這種鬆耦合趨勢，工作流與基於工作流的應用系統之間也要鬆耦合。儘量減少應用系統與工作流引擎之間的代碼連接。流程實例對象，活動實例對象和工作項實例對象等可以支持事件接口，允許應用實現以構件化形式存在的事件插件，並將此實現註冊到工作流定義對象中。在業務應用系統在執行工作流API控制工作流對象時，由工作流系統自動觸發事件實現，......

緊耦合是什麼意思，鬆耦合又是什麼意思

緊偶合就是模塊或者系統之間關係太緊密，存在相互調用。

鬆耦合系統通常是基於消息的系統，此時客戶端和遠程服務並不知道對方是如何實現的。

看一些程序設計方面的書籍 老是提到“耦合” 耦合 到底是什麼意思？鬆耦合是什麼意思

我的理解是：軟件設計中的“耦合”指，兩個功能函數之間的依賴程度。

比如，你設計的一個程序，需要你編寫10個功能函數來實現。如果這10個功能中，有9個功能都要調取第10個功能函數X10，那麼，當你在修改X10時，你就要考慮修改完成後，是否會對其它9個功能函數有影響，為了查看是否有不好影響，你就要對其它9個功能函數，一個一個進行測試。所以，為了避免產生這種後期修改的勞動量。就提倡【鬆耦合】，就是，功能函數之間，儘量依賴程度不要太高。否則，修改完一個底層函數後，會對多個上層函數，進行大量的測試。

【鬆耦合】的方法，一般是底層函數，功能儘量單一，儘量避免修改底層函數。功能相近的函數，可以設計2個以上，不要為了減少代碼量，把一個函數的功能設計的太多。

鬆耦合的對比

所謂“耦合”，指將兩個元素像鏈子一樣連接在一起。在軟件領域，“耦合”一般指軟件組件之間的依賴程度。那麼，什麼是依賴？各種依賴對耦合度和鬆散度有多大影響？軟件耦合可以發生在許多級別。必須區分生成時(編譯時)依賴和運行時依賴。在分佈環境中，為了確定系統的耦合程度，必須分析各個級別。表3-1簡要介紹了這些級別，以及這些級別與緊耦合-鬆耦合的關係。表3-1 緊耦合與鬆耦合 級 別 緊 耦 合 鬆 耦 合 物理耦合 需要直接的物理鏈接 物理中介 通信方式 同步 異步 類型系統 強類型系統（例如接口語義） 弱類型系統（例如載荷語義） 交互模式 以OO方式導航複雜對象樹 以數據為中心，獨立消息 過程邏輯的控制 集中控制處理邏輯 分佈式邏輯組件 服務發現和綁定 靜態綁定服務 動態綁定服務 平臺依賴性 對操作系統和編程語言的依賴性高 獨立於操作系統和編程語言 下面將詳細分析表3-1中的各項。在研究分佈系統的“耦合”問題時，與遠程組件的連接方式可能是最重要的技術因素。在物理級別上，物理中介支持鬆耦合。MOM系統鬆散耦合，消息隊列扮演中介角色，解耦合消息的發送者和接收者。而RPC形式的應用程序緊密耦合，因為客戶端和服務器直接交互，客戶端要求服務器可用、可訪問，以達到交互目的。如前所述，在“通信方式”級別上，同步和異步通信對耦合級別的影響經常與分佈式組件的物理鏈接密切相關。異步通信通常與鬆耦合相關。不過，這要求底層中間件能以鬆耦合方式支持異步通信。以單向RPC為例：雖然客戶端不等待服務器的應答，但單向RPC仍然緊耦合，因為只有當客戶端直接連接到服務器，而且服務器正在工作和運行時，客戶端才能發送單向請求。這是說明各種耦合度的極好例子：在適當MOM基礎上建立的異步通信比異步單向RPC調用的耦合程度更低。再來研究分佈式應用程序的“類型系統”級別的“耦合性”。可以看到，類型系統越強，系統不同組件的依賴程度也越高。無論在應用程序開發階段，還是在更改和重新配置運行的系統時，都是如此。前面分析過“接口語義”和“載荷語義”的差別。接口語義提供了顯式的接口名、操作名和強類型參數。因此，組件在這個級別上達到緊耦合的程度，因為每次更改接口時，需要考慮依賴的組件，影響會波及到整個應用程序。這樣做的好處是：可以在編譯時發現受影響的應用程序部分，使其適應和反映更改，避免不兼容的消息格式引起運行時異常。載荷語義的消息格式通常更靈活，故能降低組件的耦合級別。有些情況下，可應用消息格式驗證，如XML Schema驗證。但是，這要求參與者之間有效管理的最新模式定義。注意，使用載荷語義並不能消除更改消息格式的問題：開發人員必須瞭解受更改影響的系統部分，確保在採用新格式時，這些部分能正常運行。很多情況下，這往往意味著問題從生成時轉移到運行時。分佈式組件的“交互模式”對耦合度有何影響呢？以基於ORB的系統為例，該系統通常採用面向對象的方式在複雜對象樹中導航。客戶端不僅需要了解各個對象的邏輯，還必須瞭解如何在對象間導航，從而導致了高耦合性。RPC形式接口不支持這類複雜導航，但與分佈對象系統相比，耦合程度降低了。基於MOM的系統一般採用更簡單的交互模型，單個隊列通常已足以作為客戶端的輸入點，服務器端事務的所有輸入在單個消息中提供。在談到這個問題時，需要考慮系統是基於RPC形式服務構建，還是基於隊列和主題而構建。一般而言，主題和隊列更靈活些，通過調整隊列配置及關聯方式，允許在運行時更方便地更改系統。大多數MOM系統強大的配置管理極大地降低了系統組件......

什麼叫做鬆耦合

鬆耦合系統通常是基於消息的系統，此時客戶端和遠程服務並不知道對方是如何實現的。客戶端和服務之間的通訊由消息的架構支配。只要消息符合協商的架構，則客戶端或服務的實現就可以根據需要進行更改，而不必擔心會破壞對方。

鬆耦合通訊機制提供了緊耦合機制所沒有的許多優點，並且它們有助於降低客戶端和遠程服務之間的依賴性。但是，緊耦合性通常可以提供性能好處，便於在客戶端和服務之間進行更為緊密的集成（這在存在安全性和事務處理要求時，可能是必需的）。

系統之間採用鬆耦合方式有什麼優點？

使用鬆耦合系統的好處有兩點：一點是它適應變化的靈活性；另一點是當某個服務的內部結構和實現逐漸發生改變時，不影響其他服務。而緊耦合則是指應用程伐的不同組件之間的接口與其功能和結構是緊密相連的，因而當發生變化時，某一部分的調整會隨著各種緊耦合的關係引起其他部分甚至整個應用程序的更改，這樣的系統架構就很脆弱了。

java中的鬆耦合性

舉個簡單的例子啦

有一百人分成10個團隊做開發

你寫了一個類A，供其他人調用，怎麼辦？

簡單的方法就是把這個類打成jar包，然後給他們

他們就A a = new A();

然後調用a的方法。

但是有一天，A類升級了，怎麼辦？

再打jar包，再給其他9個組每個組發一份，告訴他們，替換一下以前的jar包。

有可能你的a中，方法簽名還發生了變化，那麼他們就得重新改代碼來適應你新的jar包了。

如果這樣的事頻繁發生呢，那麼你就等著捱罵吧。

這就是緊耦合，他們的程序緊密地耦合著你的程序。

如果是鬆耦合的話，我想我可能會定義一個接口給他們，耽後IOC的方式將實現類給他們，最好是遠程的通過webservice的方式進行調用，這樣我的A更新了，只需要切換掉遠程的A的實現類，他們根本啥也不知道，啥也不用改，就更新了功能，怎麼樣，是不是很方便？

這就是鬆耦合

spring使用什麼實現了鬆耦合

使用控制反轉(就是依賴注入)實現了鬆耦合。