Размещение пользовательского кода в пространстве имен системы

Question

Существуют ли передовые практики, согласно которым пользовательский код не следует помещать в пространство имен System? Должен ли System и его дочерние элементы быть зарезервированы для кода Microsoft?

Я спрашиваю, потому что я пишу библиотеку классов, которая будет использоваться во многих проектах, и я хотел бы, чтобы все было согласованно, поместив ее в System.InteropServices (поскольку она имеет дело с P / Invoke).

Answer 1

Это не очень хорошая идея, потому что она побеждает одно из основных преимуществ пространств имен: предотвращение конфликтов имен.Что если более новая версия фреймворка представит тип с таким же именем в этом пространстве имен?

Это особенно плохо для пространств имен System, поскольку они импортируются во многие другие фрагменты кода с директивами using, а введение пользовательских типов в эти пространства имен загрязняет область именования других исходных файлов с неожиданными идентификаторами.

Чтобы классифицировать типы, связанные с пользовательским взаимодействием, вы можете создать новое пространство имен, например MyProduct.InteropServices.

Answer 2

Я не согласен со всеми.

Я думаю, что в ограниченном подмножестве случаев (в основном с методами расширения) вполне разумно поместить код в пространство имен системы.

Вот моя сторона аргумента из цепочки писем, в которой мы обсуждали методы Extension в пространстве имен System: EPS :

---

Хорошо, вот моя сторона аргумента:

1. Мне действительно нравится минимизировать код. Это включает в себя использование.

2. Да, ReSharper подбирает методы расширения и добавляет для вас использование, но у некоторых людей нет ReSharper, и, кроме того, я предпочитаю Coderush, который на данный момент фактически (насколько я знаю) не подхватывает Пространства имен расширения.

3. Существует как минимум два разных типа методов расширения; те, которые являются вспомогательными методами для нашего приложения - включая доменные и специфичные для приложения помощники, и те, которые включают в себя функции и синтаксис, которые, по нашему мнению, должны были начинаться с языка.

Хорошим примером последнего является способность делать "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 и производили ключевые слова всегда, чтобы были видны. Однако, если это зависит от приложения, оно должно идти в своем собственном пространстве имен. 90% времени специфичные для приложения вспомогательные расширения, скорее всего, не должны быть расширениями и даже не быть статичными. Я исключаю из этого утверждения использование методов расширения для предоставления псевдонимов именам функций.

Конечно, вы можете столкнуться с некоторыми проблемами при вызове сборок, содержащих общесистемные расширения. Предположим, что я ссылался на сборку, содержащую мой метод void IEnumerable<T>.ForEach, и хотел создать собственный рубиноподобный R IEnumerable<T, R>.ForEach (который на самом деле является просто Select, но не имеет значения). Это было бы проблемой! Что мне нравится делать, чтобы смягчить эту проблему, так это определить классы расширения как внутренние, чтобы их можно было использовать только в моем проекте. Это решает проблему красиво.

Answer 3

Если вы поместите новый класс в System.InteropServices, каждый файл с предложением using System.InteropServices; будет вынужден иметь ваш класс в области видимости, что может запутать программиста. Поскольку программист не может защитить себя от этого, я бы посчитал это плохой практикой.