Лучшие практики: пространство имен методов расширения C # и продвижение методов расширения

Question

Я знаю, что уже существует сообщение , описывающее почти то же самое, но я думаю, что мое немного отличается.

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

• MyCompany.Web.Utils

и внутри у меня есть классы методов расширения. Это хорошо для меня с тем недостатком, что расширители не сразу видны нашим разработчикам программного обеспечения. Рассмотрим случай, когда у меня есть класс StringExtender, который предоставляет весьма удобный метод расширения «In» , расширяющий объект String. Имея метод расширения в вышеупомянутом пространстве имен, наши программисты не увидят метод расширения, если они явно не включают его пространство имен. Вместо этого, если бы я поместил метод расширения в пространство имен System, все сразу увидели бы его, но я прочитал, что это плохая практика .

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

Answer 1

Мы помещаем их всех в свое собственное пространство имен Company.Common.Extensions. Таким образом, если у вас есть какой-либо из наших методов расширения, у вас есть все. Кроме того, по крайней мере в моем магазине нам не нужно беспокоиться о том, что наши разработчики не знают о методах расширения. У меня есть противоположное беспокойство, перегрузка метода расширения! :)

Answer 2

Проблема здесь не в именовании пространства имен, а в отсутствии документации и образованности ваших разработчиков.

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

Answer 3

Это не проблема пространства имен, это проблема связи.

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

Помещение чего-либо в пространство имен System - это путь к катастрофе и путанице позже. Единственный раз, когда вам захочется это сделать, - это перенести функциональность «обратного порта» в более старые фреймворки, и тогда вам, вероятно, не следует делать это самостоятельно, а использовать для этого что-то вроде LinqBridge.

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

Сохраняя пространство имен, название компании в целом целесообразно, чтобы избежать путаницы.

Answer 4

Предполагая, что вы используете Visual Studio, одним из способов будет создание пользовательского шаблона класса (или изменение шаблона по умолчанию), чтобы всякий раз, когда разработчик создает новый файл класса, он автоматически получал оператор using с вашим пространством имен. См. C Настройка шаблонов Visual Studio 2005 для повышения производительности кодирования .

Answer 5

@ Juri - Если подумать, это та же проблема, что и разработчикам, знающим, что класс X существует в .NET Framework. Общение - это ключ к тому, что все члены команды используют правильные классы, будь то методы расширения или какой-то другой помощник.

Как заявил JP, я часто вижу методы расширения в некоторой подпапке, называемой Extensions. Надеюсь, когда вы заявите, что используете my.company.web.utils, пространство имен на самом деле написано на Pascal?

Даже если вы разместите их в хорошем месте, нет 100% гарантии, что другие разработчики будут их использовать.

Answer 6

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

Answer 7

Да, я считаю, что использование методов Extension в именах собственной компании - это лучшие практики. поместить его в пространство имен системы - это ленивая операция

Answer 8

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

Answer 9

Мы помещаем все в одно и то же Пространство имен и Класс, но мы используем частичные классы, чтобы держать их организованными.

Например:

ExtensionMethods-String.cs

ExtensionMethods-DataObject.cs

ExtensionMethods-Debug.cs

... и т. Д. У всех есть частичные классы ...