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

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

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

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

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

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

Ответов (6)

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

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

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

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

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

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

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

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

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

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

Core.Extensions.Base64Encode(str);

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

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

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

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

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

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

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

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

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