內部類型是否妥協了良好的API設計？

Question

在我看來，任何時候遇到內部呼叫或類型，就像我碰到一個路障。

即使他們是一樣的開源代碼訪問，仍覺得他們不是API代碼本身的可用部分。即就好像他們不鼓勵被修改一樣。

除非絕對必要，否則應該避免使用內部關鍵字？

我在問這是一個開源的API。但是，仍然不是每個人都想更改API，但大多數情況下都是用它來爲應用程序本身編寫自己的代碼。

Answer 1

沒有什麼錯在你的DLL中的內部類，是不是你的公共API的一部分。事實上，如果您有任何其他不是一個簡單的DLL更容易壞的設計標誌，如果你沒有一個內部類（或至少非公開型）

爲什麼？公共API是暴露消費者使用的對象模型的一部分的一種方法。擁有完全公共類型的API意味着您希望消費者從字面上看到DLL中的所有內容。

想想伴隨該立場出現的版本問題。字面上改變對象模型中的任何東西都是一個突破性的改變。擁有內部類型可讓您在模型中擁有極大的靈活性，同時避免對消費者造成重大改變

Answer 2

API由其公共類型和成員組成，其他任何都是實現細節。

話雖這麼說，我認爲，尤其是當你想從你的API返回的接口類型，不想暴露，你已經習慣了實現這些接口的具體類型的內部類型可以是非常有用的。這給了API設計者很大的靈活性。

Answer 3

內部類型是明確表示不在API之外的類型。你只應該標記你不想讓人看的內部事物。

我的猜測是，你對面是內部類型來了，但會一直有價值增加的公共API。我在很多項目中看到過這個。然而，這是一個不同的問題 - 與私人類型是否應該公開一樣，這也是一個問題。

在一般情況下，一個好的項目應該有內部或私有類型。他們幫助實現所需的功能集而不會使公共API膨脹。保持公共API儘可能小以提供所需的功能集是使庫可用的一部分。