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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Core.Extensions.Base64Encode(str);

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

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