我看到很多問題張貼在OC原則和一些有很好的回答，我仍然有一些懷疑這一點，下面是那些。開放封閉原則基本懷疑
1）讓我們假設我的應用程序中有註冊模塊，目前它只支持一個國家，我得到更改請求，我必須現在支持另外3個國家（註冊表格不會改變，它仍然是一樣的），它只是我必須根據國家對用戶進行分類。只有更改我的應用程序才能從UI獲取國家/地區數據並將其保存在數據庫中，是否必須在此處應用OCP。
2）OCP是否意味着我的方法（函數）中不應該有任何其他邏輯，我知道如果其他方法對對象創建不好，但如果我有一些業務邏輯要基於場景實現，我應該不如果其他情況下使用，如果更多的條件被添加，我必須修改代碼。
開放閉合原則適用於幾乎所有的設計和你的。與你描述的場景（這些場景是有效的）唯一的區別在於，你已經把它帶到了變更請求（點1）和編碼實踐（點2）。
開放封閉的原則然而是要在更高的層次上看到更多的設計層面。它也應該被看作是應該瞄準的最佳實踐，並且應該儘量接近開放式封閉設計可能的（例如，系統的最大可能部分打開進行擴展，並且系統的最大可能部分關閉以進行修改）。讓我看看這兩種情況，並解釋Open-Closed如何應用於它們 -
點1：3個新國家場景 -只有3個添加到UI字段的新值不保證設計更改。但是，如果您的代碼中具有特定於國家/地區的業務邏輯，則此更改確實會影響設計。 在國家特定邏輯的情況下，您應該設計業務邏輯實現，以便您可以編寫一個擴展基本處理程序的新服務類/國家/地區特定處理程序。該國家特定的服務調用可以被配置爲基於所選擇的實際國家來調用，或者可以基於在UI中選擇的國家來實例化國家特定的處理器。然後這是對擴展打開。另一方面，基類服務/ BaseHandler保持不變，代碼的執行順序保持不變（或者順序圖保持不變）。您的應用程序的核心因此而關閉以進行修改。
這就是Open-Closed如何應用於這一點。
點2：如果其他 -無論如果，否則打破了打開關閉規則取決於其中它被應用。如果在服務方法內的其他內部細粒度業務邏輯是絕對沒問題的。如果您正在使用它來選擇從處理程序的工廠實例化哪個處理程序，那就更好了。
但是，如果你有一個單一的服務方法來處理所有的國家並且你正在做一個if-else來檢查國家1是否保存在數據庫中，如果國家2然後忽略等等，這並不好。一個「封閉修改」設計。
希望我能夠向你解釋這個概念。
我在博客上寫了一篇關於開放封閉原則的文章，我已經詳細解釋了這個原理 - http://www.javabrahman.com/programming-principles/open-closed-principle-with-examples-in-java/。如果您仍然有任何疑問，您也可以查看它。