标签: coupling

我有一个类(让我们称它MyService)在它的构造函数中接受两个依赖项.第一个与问题无关.第二个是PaymentDetails.PaymentDetails的寿命比MyService长,后者由工厂创建以处理此特定请求.

在MyService.process(),它:

• 做一些第一依赖的东西,
• 构造一个new TransactionDetails()对象并在其上设置各种东西,
• 电话 myPaymentDetails.setTransactionDetails( td );
• 返回一些内容,说明接下来的向导中的哪个页面

PaymentDetails必要时有很多方法.它是一个实体样式对象,当用户逐步浏览大约5页时,信息就会建立在该对象中.

困扰我的是,写作我的服务类取决于整个PaymentDetails但只调用一个方法.

这困扰我,因为:

• 它将限制重用服务类的能力
• 通过阅读方法签名无法理解真正的依赖关系

我的问题是:

解决此问题的最佳方法是什么,以便我的服务类具有最小的依赖性？

我刚刚在NDC观看了Bob Martin的一集,他说在页面顶部的C#中使用"using"指令很糟糕,因为它们在组件之间创建/暗示紧密耦合.

在没有添加项目引用和using语句的情况下,有什么方法可以使用外部.dll？

我记得V6曾经让你通过ProgId的字符串创建一个对象 - 我不确定这是我正在寻找的技术,但它是一个不需要项目引用的语言示例DLL.

编辑:这是会议的链接.对不起我在演讲中没有确切的引用或分钟,我记得.

根据Demeter法则,您可以调用返回物体的方法吗？

例如

<?php
class O
{
    public function m($http)
    {
        $response = $http->get('http://www.google.com');
        return $response->getBody(); // violation?
    }
}
?>

$ http-> get()返回一个对象.这是否算作在M中创建/实例化的对象？如果你不能在它上面调用方法(根据LoD),你将如何处理这种情况？

这实际上与我之前提到过的一个问题有关,但我还是留在这个细节上.我只限于Java 1.4,我想将int类型转换为Object.我真的需要使用一个Integer类对象,或者有一种直接投射它的方法(在1.4中没有自动装箱).这种"手动装箱"的成本是否值得将整个类从第3层导入第1层,从而增加耦合？

哪种设计支持整体低耦合？为什么？

根据下一个例子:

class InvoiceGenerator
{
   function create(Invoice $invoice)
   {
      $invoice->create();
   }
}



class InvoiceGenerator
{
   function create($invoiceData)
   {
      $invoice = new Invoice();
      $invoice->create($invoiceData);
   }
}

第一个示例在InvoiceGenerator和Invoice类之间的耦合较少,因为InvoiceGenerator不需要Invoice类.此外,它不仅可以处理一个类,而且可以处理几乎没有修改的整个界面.我已多次读过这样的原则:接口代码,而不是实现.这种情况的缺点是我被迫在客户端代码中实例化Invoice类.

第二个有更多的封装.实例化和创建发票的所有过程都委托给InvoiceGenerator类.尽管两个类都是耦合的,但这是有道理的,因为"发票生成器"在没有发票的情况下不会做任何事情.

您认为哪种最合适？或者两者之间的平衡设计的关键点是什么？

我不明白"对象类之间的CBO耦合"究竟意味着什么.我发现的定义太短了,我觉得我错过了一些东西,所以如果你帮我举个例子会很棒.

这是我发现的定义:"对象类之间的耦合是它所耦合的其他类的数量的计数."

提前致谢.

从我对 OO 设计/模式/原则的所有阅读和研究中，我发现普遍的共识是松耦合（和高内聚）几乎总是更好的设计。我完全同意从我过去的软件项目经验中发言。

但是，假设某个特定的软件公司（我不在其中工作）有一些设计有问题的大型软件，可以与某些硬件进行交互。这些模块（我从未研究过）是如此紧密耦合，并且函数调用可以深入 20 多个级别来管理状态。类边界从来没有明确定义，用例也没有考虑清楚。一个优秀的软件开发人员（不是我）会提出这些问题，但只会被更高级的开发人员拒绝，因为开发实践（如 SOLID 或 TDD）并不真正适用，因为该软件已经使用“传统”方法运行多年，再改变也晚了。客户（我不知道他们是谁）最大的抱怨是产品质量。

由于上述不切实际的场景（我从来没有分开过），我想过是否存在首选甚至需要紧耦合的情况？什么情况下开发人员需要跨越模块边界并共享状态并增加依赖性并降低可测试性？有哪些系统如此复杂以至于需要这样做？我自己想不出一个好的案例，所以我希望一些更有经验的工匠可以帮助我。

谢谢。再说一遍，我不知道这家公司。

我应该写相同代码的两个版本.一个具有低耦合和高内聚力,另一个仍具有低耦合但这次具有低内聚力.我真的不明白它的区别是什么？我怎样才能具有低耦合和低内聚力？他们似乎很相关,这是不可能做到的.

有人可以解释一下吗？也许有一个例子？谢谢!

假设我有一个classA,它有自己的方法,有自己的私有字段和你有什么(基本上遵循封装标准).然后我有classB,它需要执行最终状态(通过其中一种方法获得classA,有些打破了封装)classA.然后我们classC再次需要最终状态classB.等等,让我们说classM.是否认为耦合度太高？

编辑:好吧,假设我正在设计Loot系统,这取决于是否根据敌人的失败发生掉落(每个敌人有不同的掉落几率).如果敌人被击败,那么处理战斗物的类会掷骰子,无论它是否掉落,然后我需要将该状态传播给处理战利品分配的其他类.如果有掉落,则类处理战利品执行战利品生成并分配给玩家,如果没有,则无效.

最终的执行将是这样的:

classA a = new classA;
...  //classA does its stuff
classB b = new classB(a.getFinalState());
... // again class does its stuff based on outcome of A
classC c = new classC(b.getFinalState());

等等.