-Info 类名后缀的替代方案

Question

我一直在阅读 Robert C. Martin 的 Clean Code，无意中发现了一句臭名昭著的声明：

避免使用 Manager、Processor、Data 或 Info 之类的词 类。

所以，很自然地，我尝试将-Info 排除在我的一个班级名称之外。现在，我看到了各种各样的 StackOverflow 问题，询问在 -Manager 或 -Processor 的情况下该怎么做。我见过 cmets 表示他们想不出-Data 会成为一个好的班级名称的时间。好吧，在我看来，-Data 和 -Info 似乎更难区分。特别是，例如在下面的课程中。

我有一个Server 类，如下所示：

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存储了这些服务器的信息，如下在另一个远程服务器上：

public class ServerMap {
    ConcurrentHashMap<Integer, Server> serverMap = /* ... */;
}

但是，这个HashMap只需要知道我所说的就是上面的ServerInfo。它不需要通过存储一堆它永远不会使用的变量来浪费内存。因此，需要一个 Data 类来容纳这些变量。

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<Integer, ServerInfo>。

问题在于这显然违反了清洁代码中的规则。我可以将-Info 更改为某个同义词，但是，这不是真正解决问题吗？例如，我可以称之为ServerDetails，但我看不出它与ServerData 或ServerInfo 有何不同。

我可以在不同的命名空间中重新定义Server，并只给它这些成员，但这似乎更令人困惑。

对此的最佳实践解决方案是什么？

Answer 1

我认为该声明的重点是避免在涉及类命名时使用诸如 -Data 和 -Info 之类的重载术语。我认为将 ServerDetails 之类的东西用于您要命名的对象是不合适的。毕竟，他们不是这样的吗？

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

完全使用作者提出的指导方针；指导方针。请记住，有很多人有很多意见，但很少有人能 100% 地应用。试图将每一个“最佳实践”应用到信中，你会发疯的。

Answer 2

我认为您以错误的方式看待重构。他们对ServerInfo 的正确名称（在我看来）将是Server，因为这就是服务器的实际情况。当我们处理 OOP 时，“基础”对象是带有数据的对象。例如，我们不会调用具有用户名、电子邮件和密码UserInfo 或UserData 的类，因为数据隐含在它具有成员的类这一事实中。 显然，这条规则有一些例外。使用ProfileData 对象来包含某些对用户不太重要的信息是常见的做法。

我个人可以通过两种方式重新考虑这个服务器问题。 一个是我会将基础（serverInfo）重命名为Server，将更高级别的对象重命名为ServerCommands（我很难找到合适的名称，因为我不知道该类所做的一切）

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

原因：像“ThreadHelper”这样的类名让人想知道为什么 需要以及为什么它不能只是“线程”类的一部分。是吗 实际上是适配器还是装饰器？如果是这样，请这样命名。是类 “线程”已经承担了太多的责任？如果是这样，重构和 给新类一个有意义的名字。 “帮手”什么也没说 它正在做或如何提供帮助。

这一切都与课程的实际预期目的有关。如果我看到一个名为 serverInfo 的类，我可能会也可能不会理解该信息是什么。 我个人将其命名为ServerProperties。听起来可能只是信息的同义词，但实际上更具体。当我们想到属性时，我们会想到不会改变的“一次性设置”细节。 （或者如果他们确实改变了，那是因为我们正在改变设置）。你也可以叫它ServerSettings，但我个人更喜欢属性。