我們什么時候應該使用公共的，什么時候使用私有的？

Question

當我們實現團隊解決方案中其他類目前不使用的方法時，訪問修飾符應該是公共還是私有？ 我相信“一個公開成員說，這個成員代表了該對象提供的關鍵的，已記錄的功能”。 我們僅將“實現細節”方法設為私有，並且所有將來可能有用的方法都應該公開，即使目前在其他類中沒有我們的方法的使用者。 但是我的對手說，這種方法應該是私有的。 你怎么想？

補充：讓我們更具體。 例如，有一個SqlHelper類。 其中包含用於SQL Server操作的有用功能。 特別是使用了與SQL Server的連接。 但不僅在那個班上。

例如，我需要實現公共靜態HandleSqlExeption方法（現在僅適用於SqlHelper類），該方法將處理SqlExeptions。 但我希望在所有使用SQL連接進行異常處理的操作的類中都將使用此方法（而不是簡單，例如：catch（Exception）{MsgBox {“ SqlError”};）我認為公共訪問修飾符會告訴其他同事他們可以使用這種方法，而私有將隱藏該方法，如果有人要求使用這種方法，我將需要更改代碼並重新編譯程序集。底片。

Answer 1

通常，您應該使用盡可能少的許可訪問修飾符進行編碼。

• 如果未在類外部使用該方法，請將其private 。
• 如果該方法需要用於繼承類型，則將其設置為protected 。
• 如果該方法僅在部件中使用，則將其設置為internal 。
• 僅當該方法要在部件外部使用時，才應public 。

這有助於隱藏信息，並讓您隨意更改實現。

我聽說這被描述為保護您的私人。

---

在API設計方面，您應該具有完整的API，將所有邏輯功能public為public -這就是為什么應在.NET中使用接口進行API設計，因為所有接口成員都必須是public 。 在實現類時，對於不屬於該接口的任何成員，請使用上述經驗法則-除非就用戶而言，它們構成該接口的邏輯部分。

---

因此，如果您今天使用了Read方法，則應該有一個具有相同可訪問性的互補Write方法。 這是一個很好的設計（對稱和預期），但你如何讀取或寫入應后面的專用方法被隱藏，如果公立使用它們。

Answer 2

根據名稱所描述的方法的性質，使用public和private。

public當該方法可暴露於其它的目的和

當該方法不應被其他對象訪問時為private 。

如果您的對象需要更安全，請使用private訪問說明符。 您還應該了解protected訪問說明符，它的不同之處在於，那些方法只能由繼承它們的對象訪問。

Answer 3

如果某個班級有一些東西要向外界公開，則將其設為公開，否則為私有。 它取決於類的功能和目的，而不是當前或將來的要求。

Answer 4

這是一個判斷電話。 一般而言，如果從邏輯上講，它是類為提供其提供的功能而呈現的接口的一部分，則即使沒有當前用戶，也應將其公開。 這將減少每次您要將該類用於已在使用中的實質上相同的事物時都需要修改該類的機會。

但是，這是有成本的。 您公開的每個功能都是您要提供的功能。 如果將來您決定將其從公共界面中刪除，則可能會中斷呼叫者。

例如，考慮一個地圖類。 假設您目前沒有任何調用者需要知道地圖中的項目數，並且您當前的實現具有可以輕松返回的size變量。 您可以添加getSize函數以返回地圖的大小。 從邏輯上講，它是map類公開的功能的一部分。 因此，即使現在的呼叫者不需要知道電話號碼的大小，也可以認為它應該是公開的。

但是，將來的實現完全有可能希望擺脫size變量。 增大和減小大小的開銷可能很大，並且更改實現無需知道大小。 如果公開了getSize函數並調用了它，則即使您不需要它也必須繼續跟蹤其大小，或者使該函數非常昂貴，必須實際計算大小。

說很多代碼需要知道表是否為空，並且為此目的提供了isEmpty函數。 經驗表明，如果您還提供getCount函數，則人們將執行getCount() == 0而不是isEmpty 。 今天這可能沒有什么區別，但是可能會限制您將來的實現選擇，以使getCount保持與isEmpty一樣便宜。

在可能的情況下，如果您可以輕松想象該類的不間斷用戶可以從訪問該功能中受益，並且它構成該類提供的功能的邏輯部分，那么我強烈建議將其公開。 否則，您以后可以輕松添加它。 因此，不要過分強調。 在很大程度上，這是一個風格問題，並試圖預測未來。

Answer 5

面向對象開發的基本原理； 一個類的實例應該只公開需要其客戶端訪問的內容。 請參閱鏈接並搜索“封裝”。