最近、多くのコードで、クラス/メソッドの中にハードコードされた設定（ポート番号など）の値を入れてしまい、設定もできません。SOLIDの原則とクラス内のハードコード設定
これはSOLIDの原則に違反していますか？そうでない場合は、私のチームメンバーになぜそれが良いアイデアではないと言えるのかという別の「原則」がありますか？私はちょうど「それが好きではないので悪い」と言いたいとは思っていませんが、良い議論を考えるのは難しいです。
クラス内のTCPポート番号をハードコーディングすることに対する良い議論は、 'Context independence'違反です。 GOOSからは、私の重点を置いて：
コンテキスト独立
... 「文脈の独立」ルールは、私たちは、オブジェクトが すぎたりを隠すかどうかを判断するのに役立ちます誤った情報を隠します。オブジェクトがコンテキストに依存しない場合、システムは を変更する方が簡単です。つまり、各オブジェクトに、を実行するシステムに関する知識が に組み込まれていない場合です。これにより、 私たちはビヘイビア（オブジェクト）の単位をとり、新しい 状況でそれを適用することができます。コンテキストに依存しないためには、オブジェクトが何であれ、 が実行している大きな環境について知りたい場合は、をに渡す必要があります。
Context Independenceのこの特定のケースでは、私はそれを「環境の独立」と呼んでいます。言い換えれば、ハードコードされたポート番号を持つクラスは、ランタイムOS環境に不適切な依存関係を持ちます。本来、 'ポート7778は常に利用可能です。'ということは間違っています。
SOLIDの原則は、クラス設計をカバーしています。
私はあなたが設定ファイルに設定を保存すべきであると考えているのは、通常、人を説得する特別な原理を発明することを保証するのに十分なほど論議的ではないと考えられます。 :)
ほとんどの人が、自分の開発ワークステーション以外の場所で実行されているソフトウェアを体験しようとすると、経験から分かります。
厳密にはSOLIDではありませんが、OODのもう1つの原則はThe Common Closure Principleであり、一緒に変化するクラスは一緒にパッケージ化されています。厳密にはクラスではありませんが、この考え方を構成情報に引き伸ばすことができます。例えば、ポート番号は周囲のコードとは異なる基準に基づいて変化しますが、これは違反しているようです。
単一の責任原則（SOLIDのS）は、クラスに変更する理由が1つだけあるべきだと述べています。 This articleは、モデムインターフェイスの例を示しており、接続と切断の詳細がデータの通信とは別の責任でどのように異なるのかについて説明しています。これを使用して、ポート番号がクラスの主な責任とは別の特別な「変更の理由」である理由について、同様のケースを作ることができます。