Размещение пользовательского кода в Системном пространстве имен
Есть ли любые лучшие практики, которые указывают, что пользовательский код не должен быть помещен в a System пространство имен? Если System и его дети быть зарезервированным для кода Microsoft?
Я спрашиваю, потому что я пишу библиотеку классов, которая будет использоваться через многие проекты, и я хотел бы сохранить вещи последовательными путем размещения ее в System.InteropServices (так как это имеет дело с P/Invoke).
3 ответа
Это плохая идея, потому что она сводит на нет одно из основных преимуществ пространств имен: предотвращение конфликтов имен. Что, если более новая версия фреймворка представит в этом пространстве имен тип с идентичным именем?
Это особенно плохо для пространств имен System , поскольку они импортируются во многие другие части кода с помощью директив using , и введение пользовательских типов в эти пространства имен загрязняет область именования других исходных файлов. с неожиданными идентификаторами.
Чтобы классифицировать свои настраиваемые типы, связанные с взаимодействием, вы можете создать новое пространство имен, например MyProduct.InteropServices .
Я со всеми не согласен.
Я думаю, что в ограниченном подмножестве случаев (в основном с методами расширения) вполне разумно поместить код в системное пространство имен.
Вот моя сторона аргумента из цепочки писем, в которой мы обсуждали методы расширения в пространстве имен System на EPS :
Хорошо, вот моя сторона аргумента:
Я очень нравится минимизировать код. Это включает в себя использование.
Да, ReSharper подбирает методы расширения и добавляет их для вас, но у некоторых людей нет ReSharper, и, кроме того, я предпочитаю Coderush, который на самом деле (насколько мне известно) пока не использует пространства имен расширений.
Существует как минимум два разных типа методов расширения; те, которые являются вспомогательными методами для нашего приложения, включая вспомогательные методы для домена и приложения, а также те, которые инкапсулируют функции и синтаксис, с которых, по нашему мнению, должен был начинаться язык.
Хорошим примером последнего является возможность выполнения "a {0} {1}". Format ("b", "c") или someListOfStrings.Join (", ") вместо того, чтобы выполнять String.Join (someStringList.ToArray (),", ") . Другими более спорными примерами являются IEnumerable и расширение IsNull () , которое заменяет неуклюжий объект .ReferenceEquals (null, someVar) синтаксис.
Мой аргумент состоит в том, что есть все основания для размещения этой последней классификации - ваша команда в целом согласна, что она должна быть на языке, но не должна быть - в соответствующем пространстве имен (System, System.IO, System.Linq и т. Д.) . Мы хотим, чтобы эти функции были доступны везде, точно так же, как мы предпочитаем, чтобы ключевые слова foreach и yield были всегда видимыми. Однако, если он зависит от приложения, он должен находиться в собственном пространстве имен. В 90% случаев вспомогательные расширения для конкретных приложений, скорее всего, не должны быть расширениями и даже не должны быть статичными. Я исключаю из этого оператора, используя методы расширения, чтобы предоставить псевдонимы для имен функций.
Конечно, вы можете столкнуться с некоторыми проблемами при вызове сборок, содержащих общесистемные расширения. Предположим, что я ссылался на сборку, содержащую мой метод void IEnumerable , и хотел создать свой собственный рубиноподобный R IEnumerable (который является на самом деле просто Select, но неважно). Это было бы проблемой! Что мне нравится делать, чтобы смягчить проблему, так это определять мои классы расширений как внутренние, чтобы их можно было использовать только в моем проекте. Это хорошо решает проблему.
Если вы поместите новый класс в System.InteropServices , каждый файл с будет использовать System.InteropServices; вынуждает включить ваш класс в область видимости, что может запутать программиста. Поскольку программист не может от этого защититься, я считаю это плохой практикой.