Соглашение о присвоении имен C# для дополнительных методов для интерфейса
Я обычно называю свои интерфейсы C# как IThing. Я создаю дополнительный класс метода для IThing, но я не знаю, что назвать его. С одной стороны, вызов его ThingExtensions кажется, подразумевает, что это - дополнительный класс некоторым Thing класс вместо к IThing интерфейс. Это также заставляет дополнительный класс быть отсортированным далеко от интерфейса, который это расширяет при просмотре файлов в алфавитном порядке. С другой стороны, именование его IThingExtensions делает это быть похожим на него является сам интерфейс вместо дополнительного класса для интерфейса. Что Вы предложили бы?
Править: нет a Thing класс, который реализует IThing, в ответ на некоторые комментарии.
5 ответов
Я определенно предпочитаю имя ThingExtensions , а не IThingExtensions . Причина в том, что для большинства программистов префикс I в типе подразумевает, что это интерфейс. Это и очень распространенный шаблон, и часть Руководства по проектированию .Net.
Добавление префикса I для случая метода расширения нарушает как предположения, так и установленные руководящие принципы.
Это также имеет приоритет в Библиотеке базовых классов . Большинство методов расширения, доступных для IEnumerable , содержатся в типе Enumerable .
Я не знаю ни одного стандартного соглашения для этого. Я бы использовал либо ThingExtensions, либо ThingInterfaceExtensions. Я бы держался подальше от IThingExtensions, как вы также предложили.
Я лично использовал бы IThingExtensions .
С точки зрения удобства использования, конечный пользователь никогда не видит этот класс - они включают только его пространство имен.Если пространство имен такое же, как IThing , то это не имеет значения - оно уже будет у них.
При этом я думаю, что тот факт, что это расширения для любого IThing , делает IThingExtensions наиболее очевидным. Если у вас есть класс Thing , вызов этого ThingExtensions может показаться неоднозначным (вы расширяете интерфейс или саму реализацию?).
При этом фреймворк использует совершенно другой подход. Подход фреймворка заключается в использовании класса с именем Thing для расширения IThing . Примеры см. В Enumerable (расширение IEnumerable ) и Queryable (расширение IQueryable ). Это тоже был бы очень хороший вариант.
Большинство знакомых мне программистов помещают все свои методы расширения для приложения в статический класс с именем ExtensionMethods (или что-то в этом роде), независимо от класса, который расширения модифицируют , а затем они помещают этот класс в свое основное пространство имен программы .
Их объяснение состоит в том, что если вы поместите метод расширения в то же пространство имен, что и класс, который он изменяет, вы можете спутать метод с методами, которые являются частью фактического класса, что предполагает, что метод расширения является частью исходная функциональность, когда это не так.
Их, конечно, не единодушное мнение по этому поводу. См. Здесь: Как вы управляете пространствами имен ваших методов расширения?
Я бы предпочел поместить его в папку (и пространство имен) под названием Extensions и назвать его IThingExtensions .