公共职能之间的耦合

时间:2011-10-07 05:15:37

标签: oop architecture software-design coupling

假设我有一个名为do3()的函数 为了使该函数起作用,我需要执行函数do1()和do2()。

然而,其他东西也可能需要do1()和do2()(可能是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?)会很棒。

由于

3 个答案:

答案 0 :(得分:1)

耦合是与类不是函数相关的概念。 函数应该能够调用它所在的同一个类的任何其他函数。 那里没有耦合问题。

你的第一个选择很好,do3调用do2和do2调用do1没有任何问题,只要它们都在同一个类中。

你不应该选择你的选项2,因为它要求你在任何地方重复代码。

答案 1 :(得分:0)

“假设我有一个名为do3()的函数用于该函数 工作我需要执行函数do1()和do2()。 “

Juan:根据你的描述,do3()依赖于do1()和do2()。 依赖图是

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

在这种情况下,你应该采用第二种方法。

如果你的依赖图是:

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

  • do3取决于do2

  • do2取决于do1

在这种情况下,你应该采取第一种方法。

--> : shows the dependency.

答案 2 :(得分:0)

简短的回答是,如果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...

我的观点很简单,在性能,可读性方面存在成本,甚至降低了“解耦”的声明性。在控制反转时,很少明确考虑这一点,并考虑其他框架。