公共職能之間的耦合

可以說我有一個函數叫做do3（）爲了使這個函數起作用，我需要執行函數do1（）和do2（）。公共職能之間的耦合

然而，DO1（）和D02（）也需要爲其他的東西（也許是因爲DO4（））

所有這些功能都是公共的（而且必須是公共的）。

問題，我應該如何實現代碼？

選項1：

function do3() { 
    do2() 
    do whatever is needed for do3 
} 

function do2() { 
    do1() 
    do whatever is needed for do2 
} 

function do1() { 
    do whatever is needed for do1 
}

所以，如果我叫DO3（），我相信一切都會做，雖然偶會出現

選項2

function do3() { 
    do whatever is needed for do3 
} 

function do2() { 
    do whatever is needed for do2 
} 

function do2() { 
    do whatever is needed for do1 
}

所以當我想打電話給do3（）我必須

do1() 
do2() 
do3()

我覺得第二種方法更好，因爲它具有更少的耦合，但我無法真正解釋爲什麼，它更像是一種感覺。我認爲，如果我使用選項一，一天我更改do2（）我可能有問題。

使用選項2但是我必須確保在每次我想使用do3時調用do1和do2。

如果有人有一個更好的主意（選項3？）將是偉大的。

謝謝

來源

2011-10-07 Juan Antonio Gomez Moriano

我認爲你可能會找到一本書（[在線閱讀]]（http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots= qmJTOuCz90與SIG = EZKvZBjF8QmGohatC97HsmAqG0c＆HL = EN＆EI = wj6tTqe5LcTX8gON_YyiCw＆SA = X＆OI = book_result和CT =結果＆resnum = 6＆VED = 0CEMQ6AEwBQ＃v = onepage＆q =事件％20chapter％20one％20coupling＆F = FALSE））「基於事件的編程：服用事件到了極限」別拿面值的題目 - 第一章給出了一個有洞察力的描述和方法，以減少/轉移耦合到較少形式的耦合行爲。 –

「可以說我有一個功能叫做DO3（）爲了使該功能工作，我需要的功能DO1（）和D02（）來執行。」

娟：根據您的描述do3（）依賴於do1（）和do2（）。依賴關係圖是

- ->do2() 
do3() 
    - ->do1()

在這種情況下，你應該去的第二種方法。

如果你的依賴關係圖：

do3()- ->do2() - -> do1()

即

DO3取決於DO2
DO2取決於DO1

在這種情況下，你應該去做第一種方法。

--> : shows the dependency.

來源

2011-10-07 06:15:04 vrbilgi

耦合是一個有關類而不是功能的概念。函數應該能夠調用它所在的同一類的任何其他函數。那裏沒有耦合問題。

您的第一個選擇是好的，do3調用do2和do2調用do1沒有任何錯誤，只要它們全都在同一個類中。

你不應該選擇你的選項2，因爲它會要求你隨處重複代碼。

來源

2011-10-07 05:25:45

耦合是耦合，確定它與類特別相關 - 但如果您決定將函數重構爲單獨的類，會發生什麼情況？否則我同意你的看法。 –

你好。我的糟糕的是，「函數」實際上是對象中的方法（php對象更具體）。問題在於do1（）do2（）和do3（）可能處於不同功能類的不同類中。因此請記住，它們處於不同的類別中，並且請記住do2（）可能由do6（）和do8（）調用。 –

簡短的回答是，如果DO3（）總是必須繼續DO2/DO1打電話，有沒有上下文時呼叫者可能需要執行這些調用之間的一些動作，則DO2確實應該列入do3等。我還會斷言，除非doX調用是API或其他難以改變的環境的一部分，否則避免將調用分隔開是明智的，「以防萬一」在將來需要它們分裂的情況下出現（謹慎設計原則）。

較長的回答：測試某件事情真相的一種方法是探索病理案例。把你的第二種選擇推向極致，基本上需要徹底解開功能組合，以完全消除功能;畢竟，一些函數調用do1（）do2（）do3（）並因此「耦合」到這些函數。

[肥皂盒] 靜態依賴關係（耦合）必然是一個副作用，這根本不是一個真正的命題，儘管這個概念現在很流行。靜態依賴可能看起來不靈活，但它們也易於理解，機器可驗證並且高度優化。爲了說明這一點，考慮這個假設的代碼：

person = WebRequest('/GetPerson'); 
if (person.Phone.AreaCode = '') 
    person.Phone.AreaCode = GetAreaCodeFromZip(person.Zip); 
...

邏輯這樣就可以了，而且經常被分解的原因有無數的進入或許是：

requestService = CreationFactory(IRequest); 
requestService.Configure(ConfigurationService.GetConfiguration(requestService)); 
requestService.SetEntityContext('Person'); 
response = requestService.Invoke(); 
entity = EntityService.ProcessEntity(response.Data); 
EntityService.RegisterEntityCorrectionService(entity, IAreaCorrectionService); 
... 
interface IAreaCorrectionService 
... 
class AreaCorrectionService : IAreaCorrectionService 
... 
ServiceFactory.Register(AreaCorrectionService...

我的觀點很簡單，有一個性能，可讀性等方面的成本，甚至降低了「解耦」的聲明性。在考慮控制反轉和其他框架時，這很少被明確考慮。

來源

2011-10-07 06:17:58 N8allan

公共職能之間的耦合

回答

相關問題