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

Question

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

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

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

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

Update: было принято решение о создании организации широкого методы расширения библиотеки

Answer 1

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

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

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

Answer 2

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

Core.Extensions.Base64Encode(str); 

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

Answer 3

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

Answer 4

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

Brent Simmons (автор читателя NetNewsWire RSS для Mac OS X и iPhone) только отправил сегодня о его new style rules for the use of categories и там было немного discussion in the Cocoa community вокруг этой должности.

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

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