Java 替代-Info类名称后缀

我一直在阅读Robert C.Martin的《干净的代码》，偶然发现了一句臭名昭著的话：

避免使用经理、处理者、数据或信息等字眼 班级

所以，很自然地，我试图从我的一个类名中剔除

-Info

。现在，我看到了各种各样的StackOverflow问题，询问在

-Manager

或

-Processor

的情况下如何处理。我看到过一些评论，暗示他们想不出什么时候

-Data

会是一个好的类名。嗯，在我看来，

-Data

和

-Info

似乎更难区分。特别是，例如在下面的班级

我有一个

服务器

类，如下所示：

public class Server {
    //What I would call ServerInfo
    private int id;
    private String name;
    private String address;
    private int port;
    private int connections;
    private int maxConnections;
    private int status;

    //Bunch of members that aren't ServerInfo, for example:
    private ConcurrentHashMap<String, File> files = new ConcurrentHashMap<String, File>();
    private List<String> filePaths = new List<String>();
    /* ... */

    public void start() { /* ... */ }
    public void stop()  { /* ... */ }
}

但是，这个

HashMap

只需要知道我上面说的是

ServerInfo

。它不需要通过存储一堆永远不会使用的变量来浪费内存。因此，需要一个数据类来容纳这些变量

public class ServerInfo {
    private int id;
    private String name;
    private String address;
    private int port;
    private int connections;
    private int maxConnections;
    private int status;
}

而

ServerMap

现在变成

ConcurrentHashMap

问题是，这显然违反了干净代码中的规则。我可以将

-Info

更改为某个同义词，但是，这不是真的解决了问题吗？例如，我可以称之为

ServerDetails

，但我看不出这与

ServerData

或

ServerInfo

有什么不同

我可以在不同的名称空间中重新定义

服务器

，只给它这些成员，但这似乎更让人困惑

---

解决这个问题的最佳实践是什么？

我认为这句话的重点是避免在类命名时使用诸如-Data和-Info这样的重载术语。我不认为对您命名的对象使用ServerDetails之类的东西是不合适的。毕竟，他们就是这样的，不是吗

如果ServerDetails太笼统，问问自己它们是什么类型的信息/详细信息。。。在这种情况下，它们看起来都与网络或连接相关。ServerConnectionProperties或类似的东西怎么样

---

使用作者明确规定的指南；指导方针请记住，有很多人有很多不同的观点，但很少有人能百分之百地应用。如果你试图将所有“最佳实践”都应用到这封信上，你会发疯的。

我认为你对重构的看法是错误的。在我看来，

ServerInfo

的正确名称应该是

Server

，因为这就是服务器的实际名称。当我们处理OOP时，“基本”对象就是包含数据的对象。例如，我们不会调用具有用户名、电子邮件和密码的类

UserInfo

或

UserData

，因为数据是由一个包含成员的类所暗示的。 显然，这条规则有一些例外。通常的做法是使用

ProfileData

对象来包含某些对用户不太重要的信息

我有两种方法可以考虑我个人如何重新考虑这个服务器问题。 一个是我将基（serverInfo）重命名为

Server

，将更高级别的对象重命名为类似

ServerCommands

（我很难找到合适的名称，因为我不知道类的所有功能）

我的下一个建议是基于“泛化”的思想。我们不想给类命名的最大原因是因为它概括了编程的隐含方面。几乎所有的类都倾向于关联“信息”和“数据”。这些信息或数据是什么？我想引用关于“助手”和“管理者”因素的SO主题

原因：像“ThreadHelper”这样的类名让人想知道为什么它是 以及为什么它不能只是“线程”类的一部分。它是 实际上是适配器还是装饰器？如果是这样的话，就这么说吧。是班级 “线程”已经承担了太多的责任？如果是这样，重构并 为新类指定一个有意义的名称。“助手”没有说什么 它在做什么，或者它是如何起作用的

这一切都是关于类的实际目的。如果我看到一个名为serverInfo的类，我可能会也可能不会理解这个信息是什么。

---

我个人会将其命名为

ServerProperties

。听起来它可能只是信息的同义词，但实际上它更具体。当我们想到属性时，我们想到的是“一次性设置”的细节，这些细节不会改变。（或者，如果它们确实改变了，那是因为我们正在改变设置）。您也可以将其称为

ServerSettings

，但我个人更喜欢属性。

如果不需要使用“非ServerInfo的成员群”，那么为什么要将它们放在

服务器中？你能给出更多关于它们的例子吗？@Genzer它们被
Server
使用。包含有关每个
服务器的信息的映射不使用它们。只有
ServerInfo
中的变量需要由
ServerMap
知道/存储。这对我来说似乎非常合理。作者如此绝对地陈述了这一点，我觉得这是一条需要100%遵守的规则——好像我的代码中存在一些固有的设计缺陷，因为我找不到遵循它的方法。我不能在这方面指责你。每次我接触到新事物时，我总是在挖掘“最佳实践”指导方针，以保持我在前进的道路上，这会导致大量的头痛。我试着做一些研究，选择一条道路，然后从那里开始。虽然不可否认，我发现自己有时也会陷入兔子洞。你对
ServerState
或
ServerSnapshot
有什么看法，因为它是
Server
在给定时刻的一种快照/状态。如果它捕捉到了什么，我觉得它们没问题。它们不是一次性的设置细节，不会改变，不过。例如，
连接
会随着连接的增加而改变。我排除的一处财产（意外）
public class ServerInfo {
    private int id;
    private String name;
    private String address;
    private int port;
    private int connections;
    private int maxConnections;
    private int status;
}