如何处理班级过多的问题

在几乎所有我解释了 面向对象程序设计 观点的演讲中，都有人分享这样的评论：“如果我们遵循您的建议，我们将有很多小类。” 我的回答总是一样：“我们当然会的，那太好了！” 老实说，即使您不能考虑拥有“许多类”是一种美德，也不能称其为任何真正面向对象的代码的缺点。 但是，可能会出现类成为问题的情况。 让我们看看何时，如何以及如何做。

最好的《 Eldíala la bestia》（1995年），Álexde la Iglesia

前面提到过许多“规则”，如果应用这些规则，显然会导致大量的类，包括：a）所有公共方法必须在接口中声明； b）对象的属性不得超过四个（ Elegant Objects的 2.1节）； c） 不允许使用静态方法； d）构造函数必须是无代码的； e）对象必须公开少于五个公共方法（ Elegant Objects的 3.1节）。

当然，最大的担忧是可维护性：“如果我们有300个较短的类，而不是50个较长的类，那么代码的可读性就会降低。” 如果您设计不正确，这肯定会发生。

OOP中的类型（或类）构成了您的词汇表 ，它解释了代码周围的世界-代码所处的世界。词汇表越丰富，代码的功能就越强大。 您拥有的类型越多，您对世界的理解和解释就越好。

如果您的词汇量足够大，您将说出以下内容：

阅读桌上的书。

如果词汇量少得多，则相同的短语听起来像：

用那个东西上的东西来做。

显然，阅读和理解第一个短语会更容易。 OOP中的类型也会发生同样的情况：您拥有的类型越多，代码就越具有表现力，亮度和可读性。

不幸的是，在设计Java和许多其他语言时并未考虑到这一概念。 包，模块和名称空间并没有真正的帮助，并且我们通常以诸如AbstractCookieValueMethodArgumentResolver （Spring）或CombineFileRecordReaderWrapper （Hadoop）之类的名称结尾。 我们正在尝试将尽可能多的语义打包到类名中，以使他们的用户不会怀疑。 然后，我们尝试将尽可能多的方法放在一个类中，以使用户的生活更轻松； 他们将使用其IDE提示找到正确的提示。

除了OOP，这什么都没有。

如果您的代码是面向对象的，则您的类必须很小，它们的名称必须是名词，而它们的方法名称则只能是一个单词。 这是我在代码中所做的以实现此目的：

接口是名词 。 例如， Request ， Directive或Domain 。 没有例外。 类型（在Java中也称为接口 ）是我词汇表的核心部分。 他们必须是名词。

类带有前缀 。 我的课程总是实现接口。 因此，我可以说它们始终是请求，指令或域。 我一直希望他们的用户记住这一点。 前缀帮助。 例如， RqBuffered是一个缓冲的请求， RqSimple是一个简单的请求， RqLive是一个代表“实时” HTTP连接的请求， RqWithHeader是一个带有附加头的请求。

一种替代方法是使用类型名称作为类名称的中心部分，并添加一个解释实现细节的前缀。 例如， DyDomain是一个将其数据持久存储在DynamoDB中的域。 一旦知道了Dy前缀的含义，就可以轻松了解DyUser和DyBase DyUser 。

在中型应用程序或库中，您将需要记住的前缀多达10至15个，仅此而已。 例如，在Takes框架中 ，有24,000行代码，410个Java文件和10个前缀： Bc ， Cc ， Tk ， Rq ， Rs ， Fb ， Fk ， Hm ， Ps和Xe 。 记住它们的意思并不难，对吧？

在所有240个类中 ，最长的名称是RqWithDefaultHeader 。

我发现这种用于类命名的方法相当方便。 我在以下开源项目（在GitHub中）中使用了它： yegor256 / takes （10个前缀）， yegor256 / jare （5个前缀）， yegor256 / rultor （6个前缀）和yegor256 / wring （5个前缀）。

您可能还会发现这些有趣的相关文章： 复合名称是代码的气味 ； Java代码中的典型错误 ; 您的对象封装了多少？ ; 只有一个主要的建设者 ; 为什么InputStream设计错误 ;

翻译自: https://www.javacodegeeks.com/2017/03/handle-problem-many-classes.html