The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
哪个更好：books.del(42) 还是 books.book(42).del()？我都用过，很少能分辨哪个更好。第一个选项更短，而第二个选项更面向对象。第一个选项更难扩展，而第二个选项更冗长，需要更多行代码，这意味着出错的可能性更高。你更喜欢哪个？
当然，两个选项都可以运行，但问题是哪个设计更面向对象？这似乎取决于对象 books 的大小。如果它很小，就没有必要先获取这本书，我们可以直接在那里删除。
然而，如果尺寸更大，则最好先获取“book”。
这两者之间有明确的硬性界限吗？是否存在严格的规定，或者模棱两可的问题”这个班级已经足够大了吗？”每次都应该通过投票来回答？
让我们试着给出两个极端的答案：1) 永远不够大，和2) 总是足够大。
- 如果一个类始终足够好以进行提取，我们最终会得到许多小类、几乎没有参数的方法，以及……更好的面向对象设计。
共同点是cohesion。
高度凝聚的类包括相互关联的属性和方法，而非凝聚的类则包括开发人员决定添加的任何元素，尽管其中一些元素可能并不真正属于一起。第一个答案将给我们一个凝聚度非常低的类，而第二个答案将产生大量高度凝聚的小类。
那么，第二个选项更好吗？是的，是的。更小的类，更高的凝聚度，…但是也更容易分散功能并且失去焦点。”一个对象中的所有方法”是一种更受欢迎的设计，尽管它的凝聚度较低，但很容易创建：只需将所有内容放在一个地方并完成。当然，以后会出现可维护性问题。
最重要的是，在这种情况下，没有确切的正确和错误设计之分。我们只需尽力保持类的高度凝聚性，通过减少每个类中的方法数量。如果只有几个方法，就不需要提取Book，但是一旦方法数量增加，Book就是定义新实体的完美候选。
多少方法是可以接受的？
没人知道，但是当您看到超过七个方法或超过四个属性时，我建议您质疑您的类的凝聚度。此外，当您的任何方法（构造函数除外）接受超过两个参数时，开始考虑重构。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:34
