在系統命名空間中放置自定義代碼

是否有任何狀態自定義代碼不應放置在System命名空間中的最佳做法？ System及其子代應保留爲Microsoft代碼？在系統命名空間中放置自定義代碼

我問，因爲我正在編寫一個類庫，它將用於很多項目，我想通過將它放在System.InteropServices（因爲它處理P/Invoke）來保持一致。

來源

2010-04-12 David Brown

這不是一個好主意，因爲它擊敗了名稱空間的一個主要優點：防止名稱衝突。如果更新版本的框架在該命名空間中引入了一個命名相同的類型會怎麼樣？

這對System命名空間尤其不利，因爲它們被導入許多其他代碼片段中，並且在這些命名空間中引入自定義類型會污染具有意外標識符的其他源文件的命名範圍。

要對自定義互操作相關類型進行分類，可以創建一個新的名稱空間，如MyProduct.InteropServices。

來源

2010-04-12 22:21:30

我打算創建一個'System.InteropServices'的子命名空間來避免這種情況，但我看到它可能仍然不是一個好主意。 – 2010-04-12 22:34:05

如果您在System.InteropServices中添加新類，則每個具有using System.InteropServices;子句的文件都被強制將您的類放在範圍內，這可能會使程序員感到困惑。既然程序員不能爲自己辯護，我會考慮這種不好的做法。

來源

2010-04-12 22:24:23 dtb

我不同意每個人。

我認爲在有限的案例子集中（主要是使用擴展方法），將代碼放入系統名稱空間是完全合理的。

這是我從我們已經辯論System命名空間擴展方法電子郵件線程的說法側過在EPS：

好了，這裏是我的說法的一面：

我真的很想盡量減少代碼。這包括使用。
是的，ReSharper拿起擴展方法，併爲你添加使用，但有些人沒有ReSharper，此外，我更喜歡Coderush，但它實際上並沒有（據我所知）選擇擴展命名空間。
至少有兩種不同類型的擴展方法;對我們的應用程序來說是輔助方法 - 包括域和特定於應用程序的幫助程序，以及封裝我們認爲該語言應該開始的功能和語法的幫助程序。

後者的一個很好的例子是做"a {0} {1}".Format("b", "c")或someListOfStrings.Join(", ")而不必做String.Join(someStringList.ToArray(), ", ")的能力。其他更值得商榷的例子是IEnumerable<T>.ForEach和IsNull()擴展取代笨拙的object.ReferenceEquals(null, someVar)語法。

我的觀點是，有充分的理由將後一種分類放在你的團隊的廣泛認同的範圍之內，而不是在適當的命名空間中（System，System.IO，System.Linq等）。）。我們希望這些功能在任何地方都可用，就像我們更喜歡foreach並讓yield關鍵字始終可見一樣。如果它是特定於應用程序的，它應該放在它自己的命名空間中。 90％的時間應用程序特定的助手擴展應該可能不是擴展，甚至不是靜態的。我使用擴展方法從此聲明中排除函數名稱的別名。

當調用包含系統範圍擴展的程序集時，您可能會遇到一些麻煩。假設我正在引用包含我的void IEnumerable<T>.ForEach方法的程序集，並且想要創建自己的ruby-R IEnumerable<T, R>.ForEach（實際上它只是一個Select，但沒有意識到）。這將是一個問題！我想要解決的問題是將我的擴展類定義爲內部，以便它們只能用於我的項目。這很好地解決了這個問題。

來源

2010-04-12 22:33:41

在系統命名空間中放置自定義代碼

回答

相關問題