我最近在很多代码中注意到，人们将硬编码配置（如端口号等）值放在类/方法的深处，使其难以找到，而且也无法配置。
这是否违反了 SOLID 原则？如果没有，我是否可以向我的团队成员引用另一个“原则”来说明为什么这不是一个好主意？我不想只是说“这很糟糕，因为我不喜欢它”，但我很难想出一个好的论点。
问问题
245 次
4 回答
3
反对在类中硬编码 TCP 端口号的一个很好的论点是违反“上下文独立性”。来自GOOS，我强调：
上下文独立
...“上下文独立”规则帮助我们确定一个对象是否隐藏了太多或隐藏了错误的信息。如果系统的对象与上下文无关，则系统更容易更改；也就是说，如果每个对象都没有关于它执行的系统的内置知识。这使我们能够采用行为单位（对象）并将它们应用于新情况。为了与上下文无关，任何对象需要知道它运行的更大环境都必须传入.
在这种特定的上下文独立性案例中，我将其称为“环境独立性”。换句话说，具有硬编码端口号的类对运行时操作系统环境具有不适当的依赖性，基本上是在声明“我知道端口 7778 将始终可用”，这显然是错误的。
于 2013-05-08T19:18:34.467 回答
0
SOLID 原则涵盖类设计。
我怀疑应该将配置存储在配置文件中的想法通常不会被认为具有足够的争议性，以至于需要发明一个特殊的原则来说服人们！:)
大多数人只是从经验中弄清楚，当他们第一次尝试让软件在他们自己的开发工作站以外的任何地方运行时。
于 2013-05-08T18:56:08.850 回答
0
虽然不是严格意义上的 SOLID，但 OOD 的另一个原则是通用闭包原则，它指出一起更改的类被打包在一起。虽然不完全是一个类，但您可以将此想法扩展到配置信息。由于例如端口号根据与周围代码不同的标准进行更改，因此似乎违反了这一点。
于 2013-05-08T19:02:16.047 回答
0
单一职责原则（SOLID 中的 S）指出一个类应该只有一个改变的理由。本文给出了一个Modem接口的例子，并讨论了如何连接和挂断的细节是如何与数据通信分开的，并且可能会因不同的原因而改变。你可以用它来做一个类似的例子，说明为什么端口号是一个额外的“更改原因”，与类的主要职责分开。
于 2013-05-08T19:20:00.070 回答