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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

В предстоящем выпуске Руководства по разработке рамок, второе издание, будут приведены некоторые рекомендации по реализации методов расширения, но в целом:

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

Вам также следует избегать расширения System.Object, поскольку не все языки .NET смогут вызывать метод расширения как расширение. (Например, VB.NET нужно было бы назвать его обычным статическим методом в статическом классе расширения.)

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

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

Ответ 2

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

Ответ 3

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

Core.Extensions.Base64Encode(str);

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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