Question

在处理需要相同变量实例的多个类时，创建一个中心变量是不是很好的编程习惯？

chatWindow.variables.username = userField.getText();

例如：

所以我有三个类都使用相同的变量实例

我只使用第一个类（1）

我使用类（2），（3）到类（1）

实施例：（在classTwo（）中）：

classOne.variableClass.VariableName = false;

编辑：在基本形式中，我的问题是，是否可以创建一个中心“变量类”并使用其他类通过主类访问它的相同意义。

我知道我的问题很难理解，但我确信还有另一种更简单的方法。我尝试通过第二和第三类的构造函数传递第一个类的相同实例，但我的解决方案看起来有点简单。

Answer 1

这闻起来像feature envy ......听起来像你的模特做错了。

如果需要在多个类中更改一组变量，它可能应该成为一个对象（可能甚至是一个实体）。但是您应该考虑如果您需要在其他类中更改这些值，您可能需要在同一个类中放置一些逻辑（以进行验证检查等）。

有一个额外的类只是为了保存变量通常被认为是代码气味，称为贫血域。然而，有些情况确实需要它，无论如何它可能是一个品味问题。在这种情况下，你的班级只不过是一个美化的结构。

Answer 2

最佳做法是使用依赖注入并传递所需的所有资源，而不是让类找到他们想要的内容。

使用全局变量比较简单，但随着应用程序的增长以及您希望使用单元测试，这些都是一个真正的痛苦，因为管理和维护这些变得更加困难。

Answer 3

听起来你没有正确地隔离你的课程。类可以修改其他类变量，但我会避免在一个存储可变变量的地方。这使得事情看起来像全局变量，很难管理和最好避免。有关详细信息，请参阅here。同时查找Law of Dementer，这有助于在程序中保持松耦合。

Answer 4

每个问题都有自己最好的妥协，你应该问自己一系列问题。（2）和（3）是否只需要准备访问（1），还是需要写访问权限？

你实际在做什么（从（1）创建（2）和（3）似乎很好，构建器模式，你创建你永远不能直接访问的istances）

如果需要写访问权限，应该（2）通知（3）（或反之）的变更？

一般来说，你应该尽可能地限制来自“子类”的交互（理想情况下最好避免共享某些东西，如果可能的话，但通常是这样），所以从内部（1）访问它们似乎也是比从（2）和（3）访问（1）更好的解决方案。

这种限制增加了代码的可维护性，并消除/减少了值变更通知，谁拥有谁等问题。

基本上如果用户只需要大约（1）处理，而所有其他内容都是在内部处理的，那么你已经做了很好的工作（Pimpl成语对你没什么意义吗？）

你也可以将theath（2）和（3）扩展为（1），所以就像策略模式一样。有一个优点，只有（1）需要对问题进行警告，但如果将来你需要进一步退出（1）你已经准备好了战略，你可以用最小的努力进行更新。（我总是注意到你可以编写的每个代码中都存在多个模式）。

最后，您是唯一知道所有代码详细信息的人，请始终询问您是否可以提高代码维护性，易于阅读等，可能需要升级等等。

Answer 5

由于缺少示例，我不太确定你需要什么，但也许你需要注册表模式。

基本上，您创建了一个静态“全局”类，它包含整个应用程序所需的所有变量

public abstract final class VarRegistry {
    public static final String var1 = "val1";
    public static final int var2 = 2;
}

现在，在所有需要访问这些变量的类中，您可以轻松访问和修改它们：

VarRegistry.var1 = "test";

在你开始编码之前等一下：不建议使用像这样的“全局”变量。它破坏了数据封装，因为你永远不知道这些变量何时被改变以及由谁改变。

您最好重新构建程序，以支持更安全的模式，从而正确地解决您的数据问题，例如：依赖注入。