我处于一个庞大的重构项目的中间，该代码有一个5000行的主类，该主类被注入到所有内容中，存储了所有内容并具有所有通用代码。
我不是分析和设计方面的专家，但是我已尽我所能将事情分开，并且通过重构依赖于主类的类来使用我创建的新类，我占了80％左右。
在应用程序启动时会初始化某些类型的数据，并且在应用程序的整个生命周期中几乎所有内容都可以访问这些数据。例如，有一个Config类，其中包含数百个参数。
我采用的方法是创建几个单例，两个最主要的单元是GUIData和ClientData。GUIData包含对应用程序大型机的引用，而clientdata保留对config和其他类似类的引用。
这使我可以从代码中的任何地方调用ClientData.getInstance（）。getConfig（）。getParam（“ param”），但我不认为这是最好的方法。
我考虑了单个静态类，而不是这些包含类实例的数据单例，但是某些类确实需要构造函数。
我一直在反复搜索一个星期，试图找到一种更好的方法来做到这一点，但总而言之，我总是以谈论数据库缓存的线程告终
不变的（配置）实例提供“线程安全的应用程序范围的数据访问”。Typesafe的配置（如Brian Kent在评论中所建议）确实做到了这一点。请注意，这不涉及静态类或单例。静态类和单例现在可能会满足您的目的，但将来可能会令人烦恼。它们可能很方便，但是请尝试限制其使用。
在读取和解析配置数据之后，必须进行初始化。它通常在启动其他处理线程之前在应用程序启动时完成。初始化将必须尽可能多地验证配置数据，以便快速失败并在配置数据不好的情况下终止程序。
将大量配置数据捆绑在一起可以创建“隐藏的通信线路”。例如，您更新一个值而应用程序失败，因为它也需要更新其他值。将所有配置数据放在一个文件中并从该文件中加载是完全可以的，但是您的应用程序（具有数百个配置选项）应将配置数据分为一组，以供应用程序的不同部分使用。这样可以提高隔离度，帮助进行单元测试，并使得将来更改应用程序成为可能，而不会引起太多令人讨厌的惊喜。
有两种使用一组配置数据的方法：
Settings.getInstance().getConfigForThisModule()。setConfig(ConfigForThisModule config)。第一种方法取决于不调用的约定，Settings.getInstance().getConfigForACompletelyUnrelatedModule()这可能是一个缺点。第二种方法更符合“依赖注入”，并且可能是将来的证明。您可以在重构时混合使用这两种方法，只需确保它们是一致的即可（例如，仅对应用程序所有部分中使用的配置数据使用单例方法）。
为了进一步改善使用配置数据的设计，请牢记以下（可能）将来的功能要求：更新配置文件时，将重新加载配置数据并在应用程序中使用。大多数日志记录框架设法支持此功能要求，而不会影响多线程应用程序的性能。除其他事项外，它还需要以下应用程序：
ConfigForThisModule，而应Settings.getInstance()...（或可以返回更新后的实例的某些其他方法）进行定期调用。AtomicReference用返回的新配置实例更新一样简单Settings.getInstance()...。但这也是测试配置数据集隔离性的地方：在一个模块中同时使用旧集和在另一个模块中同时使用新集应该没有问题。配置数据可以看作是一种“全局状态”。考虑到这一点，在以下两个问题中讨论了关于做什么和避免什么的进一步设计要点（部分公然复制到此答案）：
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句