Question

有一个这样的类，有两个实例变量的两个getter：

class A
{
   _fieldA;
   _fieldB;

  GetA()
  GetB()

  GetSpecialNumber(int a)
  {
      //calculation not requiring any fields
  }
}

该课程将被归类为完全缺乏凝聚力。但是，我相信在某些情况下需要这样的无状态对象，因此不应该应用内聚度量。或者这是一种错误的方法/思考？事实是，除了本材料末尾提到的一些案例外，我从未读过关于低凝聚力的好消息：http://www.aivosto.com/project/help/pm-oo-cohesion.html

Answer 1

对于这种情况，我会使用属性而不是字段，这有助于一些工具理解这是一个DTO （这是正确的事情）所以他们不再抱怨内聚和代码质量。

struct X
{
    public int A { get; private set; }
    public int B { get; private set; }
}

如果GetSpecialNumber(int a)不使用任何字段/属性，则它可以是静态方法：

public static int GetSpecialNumber(int a)

如果它将从其他地方使用，我也会将它移动到辅助类。

public static class SpecialNumberHelper
{
    public static int GetSpecialNumber(int a)
    {
        // calculation not requiring any fields
    }
}

Answer 2

不，低凝聚力不好，至少在你的目标是面向对象时不会这样。

现在，为了公平起见并警告你，这可能不是多数意见，但是DTO，豆子，属性或者你称之为的东西都没有很好地设计（正如链接文章似乎暗示的那样）。再次，只有你关心面向对象。如果你不在乎那么多，那么你当然可以决定你想做什么。

显然存在微妙之处，例如给定的度量标准是否正确，或者外力（要求）是否会将您拉向低耦合。但是，我们想要避免低耦合的原因是我们希望在一个地方一起改变的东西是为了可维护性。低耦合事物可能不会一起变化，因此可维护性较差。

低内聚力有时会导致高耦合。例如，DTO（低内聚物）通过设计导致高耦合。每当DTO中的任何更改时， all 都需要检查使用该DTO的位置。也就是说，这些地方与DTO高度耦合。

辅助/存储类的低内聚，真的错了吗？

2 个答案: