開閉原則OCP與KISS簡單原則衝突嗎？ - macerub

如何看待開閉原則（OCP）？ 有些人不認同OCP，他們認為我們應該專注於編寫簡單的程式碼。 我同意這一點，但是我沒有看到簡單性和OCP是如何不相容的。

有兩個初步要點：

1. OCP的目標不是編寫我們再也不會修改的關閉程式碼，否則將導致過度設計和前端大設計（BDUF）。 我們將用無用的抽象來填充程式碼，以解決不存在的問題。
2. 完全遵守OCP是不可能的。 無法通過新增新程式碼而不修改現有程式碼來滿足使用者要求的任何可能的更改。 我們無法預見使用者將要求的每一項變更。

考慮到這些要點，編寫簡單的程式碼非常有道理。 當使用者要求更改時，簡單的程式碼將使我們能夠輕鬆地應用更改。 而且，如果我們得到使用者的頻繁反饋的情況下。

我們將知道使用者所需的更改，並且我們將能夠建立使這些更改的應用變得更加容易的抽象。編寫簡單的程式碼，重構和新增抽象，因為它們被證明是必要的。注意YANGNI原則。

下面是您遵守OCP的方式：

• 在實際使用者需求的驅動下，OCP從重構中浮現出來。
• OCP並非來自BDUF設計人員的預期行為。

OCP的要點是：

• 抽象化：將抽象與底層細節分開；
• 將變化與保持不變分開。

OCP是否仍然有意義？ 我會說是的。 如果您編寫了一個將模組傳送文字到裝置的抽象模組，那麼在不接觸模組的情況下新增新類是否很好？ 這就是我們實現可擴充套件模組和可插入行為的方式。

banq注：當需求改變或增加時，有兩種直覺：需求改變，就要修改原有程式碼；需求新增加功能，就要新增程式碼：

需求有兩種變化：新增和修改。

程式碼有兩種變化：新增和修改。

這兩種不一定要一一對應，而是根據簡單原則和OCP原則去選擇程式碼的新增或修改來滿足需求的新增，使用程式碼的新增或修改來滿足需求的修改。

簡單原則是當下工作的簡單，OCP原則是為了讓程式碼結構簡單。這兩者都需要考慮。

程式設計第一法則：如果它執行，就不要觸碰它(修改)。OCP原則可以避免你觸碰能工作的程式碼，雖然這些程式碼執行得很奇特。