SOLID原則和類內硬編碼配置

Question

最近我注意到很多代碼中，人們在類/方法內部放置了硬編碼配置（如端口號等）值，使其很難找到，也不可配置。

這是否違反了SOLID原則？如果沒有，我還可以向我的團隊成員介紹另一個「原則」，說明爲什麼它不是一個好主意？我不想只說「這很糟糕，因爲我不喜歡它」，但我很難想出一個好的論點。

Answer 1

反對在一個類中對TCP端口號進行硬編碼的一個好的理由是'上下文無關'衝突。從GOOS，與我的重點：

上下文獨立

...的 「上下文獨立」的規則可以幫助我們確定對象是否隱藏 過多或隱藏了錯誤的信息。如果系統的對象與上下文無關，則系統更容易更改 ;也就是說，如果每個對象都沒有關於系統的內置知識，它將在其中執行。這允許我們採取行爲（對象）的單位並將其應用於新的 的情況。爲了獨立於上下文，不管對象需要什麼 瞭解它在中運行的較大環境，都必須通過。

在這個具體的案例Context Independence我稱之爲'環境獨立'。換句話說，具有硬編碼端口號的類對運行時操作系統環境有不恰當的依賴性，本質上說明'我知道端口7778總是可用'，這顯然是錯誤的。

Answer 2

固體原理涵蓋了類的設計。

我懷疑你應該在配置文件中存儲配置的想法通常不被認爲有爭議足以保證發明一個特別的原則來說服人們！ :)

大多數人只是從經驗中得出結論，他們第一次嘗試讓軟件在自己的開發工作站以外的任何地方運行。

Answer 3

雖然不是嚴格的SOLID，但OOD的另一個原則是Common Closure Principle，其中聲明一起更改的類是打包在一起的。雖然不完全是一門課程，但您可以將此想法擴展到配置信息。由於例如端口號根據不同於周圍代碼的標準而改變，似乎違反了這一點。

Answer 4

單一責任原則（SOLID中的S）聲明一個類應該只有一個改變的理由。 This article給出了一個調制解調器接口的例子，並討論瞭如何連接和掛斷的細節是與數據通信分開的責任，並且可能會因爲不同的原因而改變。你可以用它來說明爲什麼港口號碼是一個額外的「改變原因」，與班級的主要職責分開。