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