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

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

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

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

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

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

42 .net
6.08.2008 07:52:31
6 ОТВЕТОВ

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

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

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

2
6.08.2008 08:02:10
Ну да. Это верно. Но должны ли быть более конкретные рекомендации. (например, следует ли расширять класс объекта?) Следует ли расширять сторонние библиотеки?
Vaibhav 18.01.2011 20:08:33

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

Core.Extensions.Base64Encode(str);

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

3
6.08.2008 08:08:20

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

4
9.08.2008 21:25:03
Отмечая, что ни один из упомянутых проектов, по-видимому, не занимался дальнейшей разработкой с 2008 года.
DavidRR 26.12.2013 14:44:59

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

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

3
8.08.2008 07:46:19

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

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

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

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

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

7
16.08.2008 17:41:20

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

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

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

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

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

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

1
15.07.2013 20:07:20