公共职能之间的耦合

可以说我有一个函数叫做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

公共职能之间的耦合

回答

相关问题