6

我有一系列配置，尽管它们将来可能会更改，但很可能永远不必更改它们。

如果有任何遗漏或不正确，那么我系统的某个功能将无法正常工作。

是否仍应以某种配置（xml、数据库等）检索这些配置并提供给最终用户进行更改 - 或者这是一个在使用它们的类中硬编码更有意义的好情况？

我花了很长时间一次又一次地改变主意。

4

7 回答 7

5

设计师对需要改变的可能性的估计并不是做出决定的可靠标准，因为我们程序的实际使用有其特殊的方式来证明我们是错误的。

与其问自己“改变的可能性有多大？”，不如问问自己“最终用户做出改变是否有意义？” 如果答案是“是”，则使其用户可更改；否则，仅通过您的代码使其可更改。

使某些东西（数据库、配置文件、自定义 XML 文件等）可更改的特定机制并不重要。重要的是为缺少的设置提供良好的默认值，这样您的最终用户将很难通过提供部分配置来破坏您的系统。

于 2013-09-02T11:31:16.090 回答
4

最佳实践是使用任何类型的配置或属性文件，并在文件损坏/丢失时使用默认值和故障保护。这些方法具有以下优点：

  • 它可以很容易地被识别为配置文件，这意味着另一个开发人员不需要深入研究您的类来更改参数
  • 属性文件可以由 ant 等构建工具编写，因此如果您有例如测试服务器地址和生产服务器地址，则 ant 任务可以相应地更改内容
  • 即使没有它，它也可以使用默认值

缺点是增加了复杂性。

于 2013-09-02T11:28:31.450 回答
2

是的，对它们进行硬编码几乎肯定是个坏主意。如果不出意外，它会使测试（无论是自动的还是手动的）比它需要的要困难得多。使用通常的默认值在 jar中包含一个文件很容易.properties，并且将来更改它们只需要在运行时覆盖它们。如果您可以灵活安排，依赖注入通常是一个更好的选择。

于 2013-09-02T11:30:48.750 回答
0

如果配置永远不会像您所说的那样改变，那么如果您将这些属性声明为接口中的变量或单独的类并在整个程序中使用此常量，那就没问题了。
单独的属性文件仅在某些属性值不固定且依赖于环境（如数据库名称、用户名、密码等）时使用。而某些属性是固定的且不依赖于将要部署的环境（如端口号、表名）如果有的话等

于 2013-09-02T11:27:37.727 回答
0

您可以更改某些属性，而无需重新测试软件。这些属性您已经针对一系列值进行了测试，或者您确信最多可以重新启动来更改这些属性是安全的。可以使此属性可配置。

还有其他一些属性，你不能假设它们在不重新测试软件的情况下就可以工作。在这种情况下，最好对它们进行硬编码，恕我直言。这鼓励您在更改此类值时完成发布过程。您从未期望改变的价值观是一个很好的候选者。

于 2013-09-02T11:52:58.197 回答
0

这取决于您的应用程序。作为基线，它很好的设计是使用静态变量来保存程序需要的数据，而不是到处硬编码字符串和整数；这意味着将来的任何更改（即应用程序范围的字体颜色）只需要一次更改，然后是一个编译周期，一切顺利。

但是，如果这些设置是用户可配置的，那么它们就不能被硬编码，而是需要从外部源读取，而你在哪里做，是设计、复杂性和安全性的问题。

纯文本文件适用于安全性松懈且内容为纯文本的小型应用程序。SublimeText 编辑器和 notepad++ 编辑器为其主题设置执行此操作，并且效果很好。（我相信它是纯文本，也许他们现在已经转移到 XML）

更好的选择是 XML，因为它是结构化的，更易于读取/解析/写入。许多项目都使用它作为选项。需要注意的一件事是损坏的文件，在读取/写入文件时，如果用户关闭程序或 JVM 出于任何原因随机退出。你可能想看看像缓冲区这样的东西。如果缺少 text/xml 文件，还要处理 FileNotFoundExceptions。

另一种选择是某种数据库文件，它更安全一些，您可以添加应用程序级加密，并且您有多种选择。已经使用数据库后端的大型程序，如 MySQL，已经有一个数据库可供使用，因此创建一个新表并将配置存储在那里。小型应用程序可以将 SQLite 视为一种选择。

于 2013-09-02T11:30:26.683 回答
0

如果“可能”发生变化，永远不要硬编码，否则你可能会后悔并让其他人生气（很可能在大型或/和开源项目中）。如果配置永远不会改变，那么它就不再是配置而是一个常量。

仅在试验代码时使用硬编码。

如果要保存简单值，可以使用 java 属性。

看这里的例子。

祝你好运。

于 2013-09-02T11:30:30.550 回答