我注意到在最近的很多代码中，人们把硬编码的配置(如端口号等)值放在类/方法的深处，使得它很难找到，也不能配置。
这违反了SOLID原则吗?如果没有，我是否可以向我的团队成员引用另一个"原则"来说明为什么这不是一个好主意?我不想只是说"它不好，因为我不喜欢它"，但我很难想出一个好的论点。
反对在类中硬编码TCP端口号的一个很好的理由是违反了"上下文独立性"。来自GOOS，我的重点是:
上下文独立
…的"上下文无关"规则帮助我们决定对象是否隐藏太多或隐藏了错误的信息。系统更容易改变如果它的对象是上下文独立的;也就是说，如果每个对象都没有关于系统的内置知识，它在其中执行。这允许我们需要采取行为单位(对象)，并将其应用于新的的情况。要独立于上下文，无论对象需要什么必须传递给。
在上下文独立的具体情况下，我将其称为"环境独立"。换句话说，具有硬编码端口号的类对运行时操作系统环境有不适当的依赖，本质上说"我知道端口7778将始终可用"，这显然是错误的。
SOLID原则涵盖了类设计。
我怀疑应该在配置文件中存储配置的想法通常不会引起足够的争议，以至于需要发明一个特殊的原则来说服人们!:)
大多数人只是在他们第一次尝试让软件在他们自己的开发工作站以外的任何地方运行时，从经验中得出结论。
虽然不是严格意义上的SOLID，但OOD的另一个原则是通用闭包原则，它指出一起更改的类被打包在一起。虽然不是一个确切的类，但您可以将这个想法扩展到配置信息。例如，由于端口号根据与周围代码不同的标准更改，因此似乎违反了这一点。
单一职责原则(SOLID中的S)指出一个类应该只有一个改变的原因。本文给出了一个Modem接口的示例，并讨论了如何连接和挂断的细节是如何从数据通信中分离出来的，并且可能由于不同的原因而改变。您可以使用这个类似的例子来说明为什么端口号是一个额外的"更改原因"，与类的主要职责分开。