適當範圍界定的好處是什麼？

Question

所以是的，這個問題基本上就是這麼說的。當你確保私人成員/方法/任何被標記爲私人（或受保護，或公共或內部等）的適當人員時，你獲得了什麼？

我的意思是，我當然可以將所有方法標記爲公開，所有方法都應該正常工作。當然，如果我們談論良好的編程習慣（順便說一句，我是一個堅定的倡導者），如果應該將方法標記爲私有方法，那麼我會將其標記爲私有方法，而不會提出任何問題。

但是，我們暫且擱置良好的編程習慣，只是從實際的量化收益角度來看待這一點。對於我的方法，成員，班級等的正確範圍，我能得到什麼？

我在想，這通常會轉化爲性能提升，但如果有人能夠提供更多細節，我將不勝感激。

（對於這個問題的目的，我沿着C＃.NET思考更多，但是，嘿，隨意在任何語言/框架您認爲合適的提供答案。）

編輯：最指出這不會導致業績增長，是的，回想起來，我甚至不知道我爲什麼這麼想。可能缺少咖啡。在任何情況下，任何優秀的程序員都應該知道如何合理的範圍（1）幫助你維護代碼/（2）控制正確使用你的庫/應用程序/包;我對你是否從中得到的其他好處有點好奇，這並不明顯。基於下面的答案，它看起來基本上總結了最重要的兩件事情。

Answer 1

性能與方法的可見性完全無關。虛擬方法有一些開銷，但這不是我們考慮的範圍。它與維護代碼有關。您的公共方法是您的班級或圖書館的API。你作爲班級設計師想要向外界提供一些保證，未來的變化不會打破別人的代碼。通過將某些方法標記爲私有方法，您可以取消用戶依賴某些實現的能力，這些實現允許您自由隨意更改該實現。

即使沒有可見性修飾符的語言（如python）也有將方法標記爲內部並可能更改的約定。通過在_underscore（）前添加方法，您向外部世界表明，如果您使用該方法，則需要自行承擔風險，因爲它隨時可能會發生變化。

另一方面，公共方法是一種直接進入代碼的入口方式。應盡一切努力使公共方法向後兼容，以避免我上面描述的陷阱。

Answer 2

通過更好的封裝，您可以提供更好的API。只有您的類的用戶感興趣的方法/屬性纔可用：可見。 接下來，確保不應該調用/修改某些不能調用/修改的變量。

這是最重要的事情。你爲什麼認爲這會導致性能提升？

Answer 3

正如我所看到的，您通過適當的範圍界定獲得了兩個重要特徵。您的API縮小了，並且明確地集中於手頭的任務。

其次，您將得到一個不太脆弱的實現，因爲您可以自由更改實現細節而不更改公開的API。

我無法看到可訪問性修飾符如何以任何方式影響性能。

Answer 4

主要有兩種類型的方法/屬性。

1. 這對任務消耗者來說是有幫助的。 （推薦範圍：Public）
2. 這對上述方法完成任務很有幫助。 （推薦範圍：Private或Protected）

Type 1方法是任何客戶機代碼需要和不需要的任何其他方法的唯一方法。這可以避免混淆，保持簡單並防止客戶端代碼做錯事情。

Type 2方法是將類型1方法劃分成的方法。他們幫助Type 1方法完成他們的任務，並且仍然允許他們簡單，簡潔，不太複雜並且更具可讀性。它們不是真正需要客戶端代碼，而只是類/模塊本身。

一個公平的例子將是一輛汽車。你有什麼是油門踏板，剎車，變速箱等。你沒有一個接口來介紹引擎蓋下的細節。這是爲機械師。

Answer 5

在C＃編程中，它有助於確保您的API /類/方法/成員「易於正確使用且難以正確使用」。