有多少内聚力？

哪个更好： books.del(42)或books.book(42).del() ？ 我会两者都做，而我几乎无法分辨哪个更好。 第一个选择更短，而第二个选择更面向对象。 第一个选项更难扩展，而第二个选项更冗长，需要更多的代码行，这意味着出错的可能性更高。 你更倾向哪个？

《不可逆转》（2002）

当然，任何一种都可以使用，但是问题是哪种设计更面向对象？ 这似乎取决于对象books的大小。 如果是小书，则无需先买书，我们可以在那儿删除它：

 interface Books { 
   void create(String title); 
   void delete( int id); 
   void rename( int id, String title);  } 

但是，如果本书较大，最好先book ：

 interface Book { 
   void delete(); // Here! 
   void rename(String title);  }  interface Books { 
   void create(String title); 
   int total(); 
   Iterable<Book> all(); 
   Book all(String query); 
   Book book( int id); // Here!  } 

两者之间是否有明确的界限？ 是否有严格的规定，或者是模棱两可的问题：“这个课程已经足够大了吗？” 应该每次投票都回答？

让我们尝试给出两个极端的答案：1）永远不够大，以及2）永远足够大。

• 如果一个类从未准备好提取它的任何部分并将其变成新的对象，那么我们将最终得到一个非常大的类，几乎所有类中都有许多属性，方法和一长串参数。
• 如果一个类总是足以进行提取，那么我们将得到许多小类 ，几乎没有参数的方法，以及……更好的面向对象设计。

共同点是凝聚力 。

高度内聚的类包括彼此相关的属性和方法，而非内聚的类包括开发人员决定添加的内容，即使某些元素可能并不真正属于同一类。 第一个答案将给我们一个内聚力很低的班级，而第二个答案将产生大量具有高度内聚力的小班级。

因此，第二种选择更好吗？ 是的。 班级较小，凝聚力更高，但更多的机会是失去焦点并在太多地方传播功能。 “所有方法都在一个对象中”是一种更为流行的设计，尽管它的内聚性较小，这恰恰是因为它更易于创建：只需将所有内容放在一个地方并每天调用即可。 当然，稍后会出现可维护性问题。

底线是在这种情况下正确与错误的设计之间没有确切的区别。 我们只需要尽最大努力通过减少每个类中的方法数量来保持类的高度内聚。 如果只有几种方法，则无需提取Book ，但是一旦方法的数量变大， Book是新实体定义的理想选择。

多少方法可以？

没有人知道 ，但是一旦您看到七个以上的方法或四个以上的属性，我建议您质疑类的凝聚力。 另外，当您的任何方法（构造函数除外）接受两个以上的参数时，就开始考虑进行重构。

翻译自: https://www.javacodegeeks.com/2019/11/how-much-cohesion-is-enough.html