懒惰的类定义

Question

什么是懒惰类的量化定义（即一个做得太少的类）？在你看来，一个班级需要多少方法才能有资格作为懒惰？只有构造函数，getter和setter的类才有资格成为懒惰的吗？或者算作数据类？

我知道在谈到这些内容时没有严格的规则，但我很想听到不同的人的意见。

Answer 1

我认为不存在可量化的定义。这是一个背景问题和意见。

Answer 2

我认为这个网站（链接到wiki）有一个很好的定义：Code Smell Taxonomy

  

Dispensable气味的常见之处在于它们都代表了应该从源代码中删除的不必要的东西。

     

该组包含两种类型   气味（可有可无的课程和   可有可无的代码），但因为他们   我们会违反同样的原则   一起看看他们。如果是一个班级   做得还不够   删除或其责任需要   增加。情况就是如此   Lazy类和Data类   气味。未使用的代码或是   冗余需要删除。这是   重复代码的情况，   投机通用性和死代码   气味

如果一个类只有一个空构造函数，并且每个变量都有一个getter和setter，那么我认为这是一个惰性类。从本质上讲，像这样的类似乎违反了封装（虽然从技术上讲，表示可能会改变，同时仍然适应所有先前定义的get方法）。至少，类很好地提供了它们实例的不变性（在多线程程序中）。显然，某些模式（例如依赖DTO的模式）需要“数据类”（空构造函数和所有模式）。我想这意味着答案是“它取决于”，这就是我们进行代码审查的原因。

Answer 3

有些人认为数据类（只是getter和setter）是代码气味，它可能是，但数据类可以很容易地通过使用它来对抗另一种叫做primitive obsession的气味来证明。 （引用的Coding Horror文章实际上指的是两种类型的气味）

没有严格的规则。但是，一个小型或懒惰的课程比一个做得太多的课程更好，总是。使用正确的班级来完成正确的工作，首先要牢记DRY和SRP。如果“懒惰”类适合，请使用它。我还发现如果我最终得到一个懒惰的类，很容易重构它并将它与“更有用”的代码结合起来。要做到这一点要比试图打破一个“渴望”，太大的课程要容易得多。

Answer 4

在没有添加任何内容的情况下扩展Object的类在大多数情况下都是“懒惰的”并且毫无意义 - 在这种情况下，标记接口将是正确的方法（与Serializable一样）。至于“确实太少”，这取决于有问题的要求。