Coding style 为什么不建议或不可能创建最大内聚类？

我正在学习罗伯特·C·马丁（Robert C.Martin）的《干净的代码》（2009）一书，我偶然发现了衔接的概念（第10章）。 罗伯特引述：

每个方法使用每个变量的类是最大 有结合力的一般来说，不建议也不可能创建 这样的最大内聚类

不幸的是，我没有找到详细的解释。有人用真实的代码示例对此进行解释吗

---

非常感谢

把我的评论变成回答

书中定义的最大内聚通常意味着这些方法提供重叠的功能，因此存在代码重复，它们不是正交的。因此，这是一种糟糕的设计，应该通过重构公共代码和尽可能使方法正交来避免，从而消除最大的内聚性。所以我的观点是，这就是为什么它是不可取的

然而，创建最大内聚类是可能的，在某些情况下，这是完全正常的

我能想到的一个简单而实用的例子是在计算机辅助设计中表示几何形状的类

例如：

class Circle{
   float[2] center;
   float radius;

   draw() {
     hardware.draw(center[0], center[1], radius);
   }
   print() {
     print('Cicrle at '+center[0]+','+center[1]+' with radius '+radius);
   }
   scale(s) {
     center[0] *= s;
     center[1] *= s;
     radius *= s;
   }
  intersectLine(line) {
    /* compute intersection based on line and circle coordinates using both cnter and radius variables */
  }
}


class Bezier{
   float[4] controls;
   draw() {
     /* .. */
   }
   print() {
     /* .. */
   }
   scale(s) {
     /* .. */
   }
   intersectLine(line) {
     /* .. */
   }
}

正如我们所看到的，形状类是最大内聚的，考虑到对象及其方法的性质，这是完全正常的。任何实际利息的计算都需要它们的变量

---

希望这些例子和解释能有所帮助。

你明白为什么不建议这样做吗？这意味着代码和方法不是模块化的，也不是相互正交的，可能存在一些重复和重叠的功能，需要重构。现在，关于可能性部分，我可以举一些非常内聚的类的例子作为概念证明，但它们不是现实的例子。可能一个非常内聚的类的实际例子是在设计中表示几何形状的类。几乎所有的方法都使用了每个形状的所有变量。例如，圆的中心和半径是变量，这些变量用于与圆对象相关的所有方法，例如

绘制

，

缩放

，

移动

，

打印

，

计算intersectionwithline

，等等。。