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

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、Bean、属性或您称之为的任何东西都没有经过精心设计（正如链接文章所暗示的那样）。同样，仅当您关心面向对象时。如果你不在乎那么多，那么你当然可以决定你想做什么。

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

低内聚有时会导致高耦合。例如，DTO（低内聚对象）通过设计导致高耦合。每次 DTO 中的任何东西发生变化，所有使用该 DTO 的地方都需要检查。也就是说，这些地方与 DTO 高度耦合。

Answer 2

对于这种情况，我将使用属性而不是字段，这有助于一些工具理解这是一个 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
    }
}