Соглашение об именах C # для методов расширения для интерфейса - PullRequest
32 голосов
/ 23 апреля 2010

Обычно я называю свои интерфейсы C # IThing.Я создаю класс метода расширения для IThing, но я не знаю, как его назвать.С одной стороны, при вызове этого ThingExtensions кажется, что это класс расширения некоторого класса Thing вместо интерфейса IThing.Это также позволяет сортировать класс расширения по отношению к расширяемому интерфейсу при просмотре файлов в алфавитном порядке.С другой стороны, присвоение ему имени IThingExtensions делает его похожим на сам интерфейс, а не на класс расширения для интерфейса.Что бы вы предложили?

Редактировать: В ответ на некоторые комментарии не существует класса Thing, который реализует IThing.

Ответы [ 6 ]

30 голосов
/ 23 апреля 2010

Я определенно предпочитаю имя ThingExtensions вместо IThingExtensions. Причина в том, что для большинства программистов префикс I для типа подразумевает, что это интерфейс. Это очень распространенная модель и часть .Net Design Guidelines.

Добавление префикса I для случая метода расширения нарушает как допущения, так и установленные правила.

Для этого также есть приоритет в Библиотеке базовых классов . Большинство методов расширения, доступных для IEnumerable, содержатся в типе Enumerable.

15 голосов
/ 23 апреля 2010

Я бы лично использовал IThingExtensions.

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

При этом я думаю, что тот факт, что это расширения для любого IThing, делает IThingExtensions наиболее очевидным. Если у вас есть класс Thing, вызов этого ThingExtensions может показаться неоднозначным (расширяете ли вы интерфейс или саму реализацию?).

При этом в каркасе используется совершенно другой подход. Подход фреймворка заключается в использовании класса с именем Thing для расширения IThing. Для примеров см. Enumerable (расширение IEnumerable) и Queryable (расширение IQueryable). Это также было бы очень хорошим вариантом.

3 голосов
/ 08 июля 2017

Я выбрал немного другой подход, и вместо суффикса с Extension изменил стратегию именования на префикс класс, содержащий методы расширения с Extend; мое объяснение таково:

  • Как указано в ответе Рида Копси , очень ( очень ) редко будет клиентский код ссылаться на содержащий класс напрямую, поскольку самой точкой методов расширения является эмуляция ссылочных методов. Они не будут видеть классы, поэтому выбор соглашения о присвоении имён классов должен оказать незначительное влияние.
  • Классы должны быть static, и поэтому вы никогда не будете их создавать. Поэтому вы никогда не получите семантическую странность new ExtendThing() в отношении имен.
  • Все ваши Extend* классы визуально сгруппированы с сортировкой альфа-файлов.
  • Что касается вашего вопроса, то здесь нет путаницы с префиксами именования интерфейсов; Вы можете иметь ExtendThing и ExtendIThing и (IMO) их намерение и цель ясны.

namespace MyCompany.Extensions
{
    public static class ExtendObject { }

    public static class ExtendDateTime { }

    public static class ExtendIEnumerable { }
}
3 голосов
/ 23 апреля 2010

Большинство известных мне программистов помещают все свои методы расширения для приложения в статический класс, называемый ExtensionMethods (или что-то в этом роде), независимо от того, какой класс изменяет расширение , и затем они помещают это класс в их основном пространстве имен программ .

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

Конечно, это не всеобщее согласие. Смотрите здесь: Как вы управляете пространствами имен ваших методов расширения?

0 голосов
/ 23 апреля 2010

Я не знаю ни одного стандартного соглашения для этого. Я бы использовал либо ThingExtensions или ThingInterfaceExtensions. Я бы держался подальше от IThingExtensions, как вы также предложили.

0 голосов
/ 23 апреля 2010

Я бы предпочел поместить его в папку (и пространство имен) с именем Extensions и назвать ее IThingExtensions.

...