Как вы управляете пространствами имен ваших методов расширения?

Question

Используете ли вы глобальное, универсальное пространство имен для всех ваших методов расширения, или вы помещаете методы расширения в то же пространство имен, что и класс (ы), которые они расширяют?

Или вы используете какой-то другой метод, например приложение или пространство имен для конкретной библиотеки?

Я спрашиваю, потому что мне нужно расширить System.Security.Principal.IIdentity и поместить метод расширения в System.Security.Principal Пространство имен, кажется, имеет смысл, но я никогда не видел, чтобы это делалось таким образом.

Answer 1

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

• Если вы пишете расширение для Uri, поместите расширение в System.
• Если это расширение для DataSet, поместите его в System.Data.

Кроме того, Microsoft говорит это о методах расширения:

В общем, мы рекомендуем вам реализовать методы расширения экономно и только когда ты должен. Всякий раз, когда возможно, клиентский код, который должен расширяться существующий тип должен сделать это путем создавая новый тип, полученный из существующий тип.

Подробнее о методах расширения см. на странице MSDN о методах расширения.

Answer 2

Если они являются методами расширения, используемыми во всем решении (например, более 60% классов), я помещаю их в базовое пространство имен решения (поскольку они будут автоматически импортированы в родительское пространство имен, без импорта общего вещи каждый раз).

В этой категории такие вещи, как:
.IsNullOrEmpty(this string value) и .HasValue(this string value)

Однако, если они очень специфичны и редко используются, я помещаю их в пространство имен BaseNamepace.Extensions, поэтому их необходимо импортировать вручную и не показывать в заглавных буквах по всему миру.

Answer 3

Я бы рекомендовал поместить все ваши методы расширения в одно пространство имен (кстати, это то же самое, что Microsoft сделала с Linq, поместив их в один класс 'Extensions' внутри пространства имен 'System.Linq').

Поскольку Visual Studio не дает подсказок о том, как найти метод расширения, который вы хотите использовать, он уменьшает путаницу, поскольку запоминает только одно пространство имен.

Answer 4

Я проголосовал за ответ от пользователя 276695, который казался самым простым решением. Однако я нашел еще лучшее решение: вообще нет пространства имен. Вы можете поместить статический класс с методами расширения в самый корень файла, не оборачивая вокруг него никакое объявление пространства имен. Тогда методы расширения будут доступны без импорта / использования какого-либо пространства имен. †

Я немного обеспокоен тем, что меня лишат голоса нацистов из пространства имен. Но я чувствую себя обязанным отстоять немного неортодоксальную позицию. По крайней мере, в своей работе (ИТ) я обнаружил, что большинство моих пользовательских инструментов проще поддерживать без пространств имен и помещая все в одно гигантское анонимное пространство имен. Я уверен, что есть и другие программные вселенные, где это тоже не сработает. Но, учитывая разные условия и предпочтения, я просто хотел отметить, что вы можете объявить классы без пространств имен, даже классы с методами расширения - для тех, кто также находит гигантское анонимное пространство имен лучше.

† Вы также можете сохранить один уровень отступа. :-) И даже с 3 гигантскими мониторами я всегда ищу способы сэкономить экранную недвижимость.

Answer 5

Если вы поместите их в пространство имен выше, чем ваше текущее, они будут видны автоматически.

Так что, если у вас есть пространства имен для таких проектов, как:

AdventureWorksInc.Web
AdventureWorksInc.Logic
AdventureWorksInc.DataAccess

Затем объявите ваше расширение непосредственно в:

namespace AdventureWorksInc
{
   public static class HtmlHelpers
   {
       public static string AutoCloseHtmlTags(this string html)
       {
           //...
       }

   }
}

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

Однако вышеприведенное расширение демонстрирует возможный недостаток. Из-за того, что он работает со строками, он теперь будет отображаться как метод расширения для всех строк, включая те, которые на самом деле не являются HTML. На самом деле это не проблема с определением пространства имен, а просто неправильное использование метода расширения. Это должна быть обычная статика, требующая стандартного параметра, поэтому вызов является явным.

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

Answer 6

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

Как правило, я создаю пространство имен, добавляя к своему имени компании часть пути к пространству имен перед расширяемым пространством имен, а затем добавляю суффикс ".Extensions"

Например, если я расширяю (без веской причины) ::System.Text.StringBuilder, потому что он запечатан, тогда я добавлю свои расширения в пространство имен ::CodeCharm.System.Text.Extensions.

Это эмпирическое правило, когда я делаю расширения, которые, как я подозреваю, могут повторно использовать эти расширения в других решениях.