SOLID原则和类内的硬代码配置

Question

我最近在很多代码中都注意到，人们在类/方法的深处放置了硬编码配置（如端口号等），使其难以查找，也无法配置。

这违反了SOLID原则吗？如果没有，是否还有另一个“原则”，我可以向我的团队成员介绍为什么这不是一个好主意？我不想只说“这很糟糕，因为我不喜欢它”，但我很难想出一个好的论点。

Answer 1

反对对类中的TCP端口号进行硬编码的一个好理由是违反“上下文独立性”。来自GOOS，强调：

  

背景独立

     

......   “上下文独立性”规则可帮助我们确定对象是否隐藏   太多或隐藏错误的信息。系统更容易更改   如果它的对象与上下文无关;也就是说，如果每个对象都没有   关于系统执行的内置知识。这允许   我们采取行为（对象）单位并将其应用于新的   的情况。与上下文无关，无论对象需要什么   了解在中运行的较大环境必须通过。

在Context Independence的这个具体案例中，我称之为'环境独立'。换句话说，具有硬编码端口号的类对运行时OS环境具有不适当的依赖性，基本上声明'我知道端口7778将始终可用'，这显然是错误的。

Answer 2

SOLID原则涵盖了课堂设计。

我怀疑你应该将配置存储在配置文件中的想法通常不会被认为是有争议的，因此需要发明一个特殊的原则来说服人们！ :)

大多数人只是从经验中弄清楚，他们第一次尝试让软件在他们自己的开发工作站以外的任何地方运行。

Answer 3

虽然不是严格的SOLID，但OOD的另一个原则是Common Closure Principle，它指出一起更改的类被打包在一起。虽然不完全是一个类，但您可以将这个想法扩展到配置信息。从例如端口号根据与周围代码不同的标准而变化，似乎违反了这一点。

Answer 4

单一责任原则（SOLID中的S）规定一个班级应该只有一个改变的理由。 This article给出了一个调制解调器接口的示例，并讨论了如何连接和挂起的细节如何与数据通信分开，并且可能由于不同的原因而改变。您可以使用此方法来说明为什么端口号是一个额外的“改变原因”，与类的主要职责分开。