Используете ли вы глобальное, полное пространство имен для всех ваших методов расширения, или вы применяете методы расширения в том же пространстве имен, что и классы (классы), которые они расширяют?
Или вы используете какой-то другой метод, например, пространство приложений или библиотеки?
Я спрашиваю, потому что мне нужно расширить System.Security.Principal.IIdentity, и, по-видимому, использование метода расширения в пространстве имен System.Security.Principal имеет смысл, но я никогда не видел, чтобы это делалось именно так.
Я бы рекомендовал разместить все ваши методы расширения в одном пространстве имен (кстати, это также то, что Microsoft сделала с Linq, поставив их в один класс "Расширения" внутри пространства имен System.Linq).
Так как Visual Studio не дает никаких указаний о том, как найти метод расширения, который вы хотите использовать, это уменьшает путаницу, только имея в виду одно пространство имен.
Поместите расширения в том же пространстве имен, что и классы, которые они распространяют. Таким образом, когда вы используете класс, расширения доступны вам.
Кроме того, Microsoft говорит о методах расширения:
В общем, мы рекомендуем вам применять методы расширения экономно и только тогда, когда вам нужно. Всякий раз, когда возможно, клиентский код, который должен распространяться существующий тип должен создание нового типа, полученного из существующий тип.
Дополнительные сведения о методах расширения см. в странице MSDN о методах расширения.
Если это методы расширения, используемые во всем решении (например, более 60% классов), я помещаю их в базовое пространство имен решения (так как они будут автоматически импортированы в родительском пространстве имен, не импортируют общие каждый раз).
В этой категории, например: .IsNullOrEmpty(this string value) и .HasValue(this string value)
Однако, если они очень специфичны и редко используются, я помещаю их в пространство имен BaseNamepace.Extensions, поэтому их нужно вручную импортировать и не показывать в intellisense всевозможные помехи.
Я поддержал ответ от user276695, который казался самым простым решением. Однако я нашел еще лучшее решение: никакого пространства имен вообще. Вы можете поместить статический класс с методами расширения в самый корень файла, не обертывая вокруг него никакое объявление пространства имен. Тогда методы расширения будут доступны без необходимости импорта/использования любого пространства имен. †
Я немного обеспокоен тем, что я проголосовал от имен нацистов. Но я чувствую себя вынужденным отстаивать немного неортодоксальную позицию. По крайней мере, в моей работе (ИТ) я обнаружил, что большинство моих пользовательских инструментов проще поддерживать без пространств имен и размещать все в одном гигантском анонимном пространстве имен. Я уверен, что есть другие программные юниверсы, где это не сработает. Но различия и обстоятельства различны, я просто хотел указать, что вы действительно можете объявлять классы без пространств имен, даже классы с методами расширения - для тех, кто лучше находит гигантское анонимное пространство имен.
† Вы также можете сохранить один уровень отступов.:-) И даже с тремя гигантскими мониторами я всегда ищу способы сохранить экранную недвижимость.
Моя практика заключается в том, чтобы поместить расширения в пространство имен, которое отличается от еще четкого определения пространства имен источников, которое я расширяю.
Как правило, я создаю пространство имен путем префикса части "название компании" пути пространства имен перед пространством имен, которое я расширяю, а затем суффикс его с ".Extensions"
Например, если я расширяю (без уважительной причины) ::System.Text.StringBuilder, потому что он запечатан, тогда я поместил свои расширения в пространство имен ::CodeCharm.System.Text.Extensions.
Это правило большого пальца, когда я делаю расширения, которые, как я подозреваю, могу повторно использовать эти расширения в других решениях.
Если вы помещаете их в более высокое пространство имен, чем ваше текущее, они будут отображаться автоматически.
Итак, если у вас есть пространства имен для таких проектов, как:
AdventureWorksInc.Web
AdventureWorksInc.Logic
AdventureWorksInc.DataAccess
Затем объявите расширение напрямую:
namespace AdventureWorksInc
{
public static class HtmlHelpers
{
public static string AutoCloseHtmlTags(this string html)
{
//...
}
}
}
Этот метод расширения будет отображаться всякий раз, когда вы пишете код в любом пространстве имен субаренды AdventureWorksInc без необходимости использования оператора.
Однако вышеуказанное расширение демонстрирует возможный недостаток. Из-за того, что он работает со строками, он теперь будет отображаться как метод расширения для всех строк, включая те, которые на самом деле не являются HTML. На самом деле это не проблема с областью определения пространства имен, а просто неправильное использование метода расширения. Это должно быть постоянным статиком, для которого требуется стандартный параметр, поэтому вызов явственен.
Обычно хорошо продуманные методы расширения с соответствующими типизированными параметрами не будут отображаться по типам, которые он никогда не применял.