Каковы наилучшие методы использования методов расширения в .Net?

Question

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

Итак, каковы, по вашему мнению, наилучшие практики использования Методов расширения?

Должны ли команды разработчиков создавать библиотеку методов расширения и развертывать их в различных проектах?

Должен ли существовать набор общих методов расширения в виде проекта с открытым исходным кодом?

Обновить:решили создать общеорганизационную библиотеку методов расширения

Answer 1

Предстоящий выпуск Руководства по проектированию фреймворка, 2-е издание, будет содержать некоторые рекомендации по внедрению методов расширения, но в целом:

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

Вам также следует избегать расширения System.Object как не всех .СЕТЕВЫЕ языки смогут вызывать метод расширения как расширение.(VB.NET например, нужно было бы вызвать его как обычный статический метод в классе static extension.)

Не определяйте метод расширения в том же пространстве имен, что и расширенный тип, если только вы не расширяете интерфейс.

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

Answer 2

возможно, вы захотите взглянуть на http://www.codeplex.com/nxl и http://www.codeplex.com/umbrella которые оба являются библиотеками методов расширения.Лично я не просматривал исходный код, но я уверен, что ребята из него смогли бы дать вам несколько хороших советов.

Answer 3

Я включил свои методы расширения в свои основные библиотеки в классе Utils, потому что люди, работающие с моим фреймворком, скорее всего, найдут эти методы полезными, но для массового развертывания, когда у конечного разработчика может быть выбор библиотек методов расширения, я бы посоветовал поместить все ваши расширения в их собственное пространство имен, даже в их собственный файл проекта, чтобы люди могли добавлять ссылку или инструкцию using или просто там, где требуется, вот так:

Core.Extensions.Base64Encode(str);

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

Answer 4

Язык Objective-C имеет "Категории" с начала 1990-х годов;по сути, это то же самое, что и методы расширения .NET.При поиске лучших практик вы, возможно, захотите посмотреть, какие эмпирические правила разработали разработчики Objective-C (Cocoa & NeXT) вокруг них.

Брент Симмонс (автор программы чтения RSS NetNewsWire для Mac OS X и iPhone) только что опубликовал сегодня о своем новые правила оформления для использования категорий и там было немного обсуждение в сообществе Какао вокруг этого столба.

Answer 5

Я думаю, что это зависит от того, какой цели служат методы расширения.

• Методы расширения, относящиеся к конкретным бизнес-потребностям проекта (независимо от того, связаны ли они с базовыми типами данных или пользовательскими объектами), не должны включаться в библиотеку, которая будет распространяться по нескольким проектам.
• Методы расширения, которые относятся к базовым типам данных (int, string и т.д.) Или обобщениям, имеющим более широкое применение, могут быть упакованы и распределены по проектам.

Следите за тем, чтобы не включать глобально методы расширения, которые мало применимы, поскольку они просто засоряют intellisense и могут привести к путанице и / или неправильному использованию.

Answer 6

Когда я впервые узнал о Расширениях, я действительно злоупотреблял ими.

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

Некоторые из причин, по которым я перестал их использовать, указаны в ссылке на блог Скотта выше, например, "Дважды подумайте, прежде чем расширять типы, которыми вы не владеете".Если у вас нет контроля над исходным кодом для типов, которые вы расширяете, вы можете столкнуться с проблемами / коллизиями в будущем, если в исходный тип будут внесены некоторые дополнения / изменения, такие как перенос вашего проекта на более новую версию .NET.Если более новая версия .NET включает метод того же типа, что и ваше расширение, кто-то будет заблокирован.

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

При простом чтении кода вы не можете определить, является ли метод расширением или просто стандартным методом NET API для данного типа.

Меню intellisense может очень быстро стать запутанным.