С какой буквы желательно начинать имена интерфейсов

Соглашения об именах Java

Соглашения об именовании Java – это рекомендации и рекомендации по написанию кода на Java. Они делают наш код последовательным и легким для чтения другими разработчиками Java.

• Автор записи

При написании кода на Java рекомендуется соблюдать определенные соглашения об именовании. Соглашения об именовании Java обеспечивают некоторую форму единообразия в вашем коде. Это облегчает чтение вашего кода другими разработчиками.

Хотя это не жесткие правила, лучше всего следовать этим правилам при написании кода.

1. Соглашения об Именовании Пакетов Java

• Имя пакета должно быть в маленьком футляре.
• В случае, если слов несколько, разделите их точкой.
• Префикс должен быть одним из доменных имен верхнего уровня, таких как com, edu, gov, mil, net, org, или одним из английских двухбуквенных кодов, идентифицирующих страны. (В США, Великобритании)

2. Соглашения об именовании классов и интерфейсов

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

3. Соглашение об именовании методов Java

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

4. Соглашения об Именовании переменных Java

• Имена переменных не должны начинаться с символа подчеркивания (_) или знака доллара ( $ ).
• Начинайте имена переменных со строчной буквы, при этом каждое последующее слово должно содержать первую букву в верхнем регистре.
• Избегайте использования односимвольных имен переменных (i,j,k), за исключением временных одноразовых переменных.
• Имя переменной должно указывать на использование переменной.

5. Соглашения об именовании Констант

• Имя константы должно быть в верхнем регистре.
• В случае, если слов несколько, разделите их подчеркиванием (“_”).

Вывод

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

Правила объявления интерфейсов. «I» или «!I»?

Кто может адекватно объяснить почему стоить объявлять интерфейсы с буквой «I»:

Или почему НЕ стоит этого делать:

Я .NET Developer и случайно в команде Java-еров смотря на их код сказал: «ОМГ, как можно объявить интерфейс без буквы `I`?». После этого пользуясь численным приемуществом они меня благополучно смешали с дерьмом. =*(

Так вот, как же все-таки правильнее? И желательно основываться не на своих предпочтениях а как-нить обосновать.

• Вопрос задан более трёх лет назад
• 3071 просмотр

• Facebook
• Вконтакте
• Twitter

Никакой «официальной» жесткой конвенции на этот счет нет. Как уже указал RGV, какую конвенцию использовать — личное дело команды / фирмы / техдира.
Я сам в свое время пришел к Java из Pascal и .NET, и тоже придерживаюсь нотации с I, т.к. это позволяет в коде визуально отличить интерфейс от класса. Просто для примера:

При взгляде на такой код сразу понятно, кто из ху, без всяких дополнительных кликов, наведения курсора и прочих пританцовываний с IDE.
И хотя это никак явно не помешает креативному балбесу влепить класс там, где нужно использовать интерфейс, это поможет проводящему ревью заметить грабли невооруженным глазом 🙂 С моей точки зрения цена такого удобства в 1 (один !) доп. символ в имени вполне оправдана.

Как объявлять имена конструкторов, интерфейсов, пакетов в Java

При написании имен интерфейсов / классов необходимо помнить следующие моменты:

• Первая буква имени интерфейса / класса должна быть заглавной, а остальные буквы маленькими (смешанный регистр).

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

• Поддерживать имена интерфейсов простыми и наглядными.
• Лучше не использовать аббревиатуры при написании имен интерфейсов / классов.

Пример

Как писать имена пакетов в Java?

При выборе имени пакета вы должны соблюдать следующее:

• Имя пакета должно быть маленькими буквами.
• Предлагается начать имя пакета с уровнем домена верхнего уровня с последующим поддоменом, например: com.example.hrvector.

Пример

Вы можете объявить пакет как в.

Выполнение пакета

Вы должны скомпилировать файл с пакетами с помощью опции -d, как показано ниже:

После компиляции, вы можете увидеть файлы классов класса, созданных в месте com/mypackage/tutorialspoint.

Средняя оценка 0 / 5. Количество голосов: 0

Спасибо, помогите другим — напишите комментарий, добавьте информации к статье.

Или поделись статьей

Видим, что вы не нашли ответ на свой вопрос.

Помогите улучшить статью.

Напишите комментарий, что можно добавить к статье, какой информации не хватает.

Зачем ставить перед именами интерфейсов C # букву «I»

Я не вижу никакой выгоды. Дополнительный префикс просто загрязняет API.

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

Я вижу два голоса, чтобы закрыть — но я не уверен, что это действительно точная копия запроса на альтернативы. Если меня кто-то убедит, я проголосую за закрытие. (Пожалуйста, оставьте комментарий.) — Norman Ramsey

Не дублируется и на самом деле хороший вопрос. — OscarRyz

Не дубликат, но Джон Лимджап, кажется, думает иначе. Что я могу сделать? — i3ensays

Это был не только Джон Лимджап. За него должны проголосовать 3 человека, он просто стал третьим, кто сделал это. — mmcdole

@Simucal — Спасибо за разъяснение. Можно ли проголосовать за его открытие? Было бы полезно, если бы избиратели предоставили ссылку на предполагаемый дубликат. — i3ensays

18 ответы

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

Например, если у вас есть:

Просто прочитав его, я могу с уверенностью предположить, что IPet и IMammal, вероятно, являются интерфейсами.

.NET CLR допускает наследование одного класса. Итак, если у меня есть базовый класс. я могу наследовать от него только один класс. Давайте изменим интерфейс IPet на базовый класс. Теперь наш пример становится

Я наследую от класса Pet и реализую интерфейс IMmmal.

Если бы мы сделали то, что вы предлагаете, и убрали букву «Я», то получили бы вот это:

От какого класса я наследую? Какой интерфейс я реализую? Это сбивает с толку, верно? (К вашему сведению. вы должны всегда ставить базовый класс первым, поэтому вы можете поспорить с этим. но если вы настаиваете на удалении буквы I из префикса имен интерфейсов, я сомневаюсь, что вы также следуете этой практике)

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

Это имеет смысл. Итак, в C# «расширения и реализации» Java смешаны вместе? — Оскар Риз

Я следую упомянутому вами соглашению «базовый класс всегда первый». Тем не менее, я не могу согласиться с вашим утверждением, что «соглашение об именах легко говорит мне многое о моем объекте». Дело в том, что различие между интерфейсом, абстрактным/конкретным классом, перечислением, стойками и т. д. не имеет для меня смысла на уровне API. — i3ensays

Почему мы не ставим перед абстрактными/конкретными типами префикс «A»/«C», перечисления — «E», структуры — «S» и т. д.? — i3ensays

Довольно иронично, что java действительно сделала это правильно. Интерфейсы больше не имеют префикса «I», но на самом деле это считается ПЛОХОЙ практикой. См. «Эффективная Java» Джошуа Блоха. — Андрей Дроздюк

К чему это не относится, так это к более фундаментальному вопросу о том, почему вам нужно идентифицировать тип как интерфейс, не больше, чем вам нужно определить, является ли он классом или структурой. или является ли он абстрактным или нет. или содержит ли он члены-экземпляры или только статические. Я думаю, что да, но я не уверен, какой лучший ответ на вопрос, почему. — Чарльз Бретана

Мне также это нравится, потому что я могу прочитать это как «I verb-behavior», как в «ICanSave» или «IDoDoubleEntry» и т. д.

Возможно, префикс должен быть «Я». — макенир

да, можно утверждать, что подразумевается «Am».. «IAmEnumerable», возможно, было бы яснее, хотя и длиннее. — Чарльз Бретана

Я всегда нахожу названия своих интерфейсов немного похожими на лолкотов. «ICanHasЧизбургер» — Иэн Галлоуэй

Разве это не противоречит соглашениям об именах C#? ICanSave должно быть ISaveble . — Вапид Линус

@CharlesBretana Я просто подумал, потому что .NET называет свои интерфейсы как IClonable , IDisposable IComparable и не ICanClone , ICanDispose или, ICanCompare . — Вапид Линус

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

Тем не менее, я все еще использую его, потому что в этом случае IInterface рекомендуется Microsoft, а «стандарт лучше, чем лучше».

Я тоже никогда не был поклонником венгерского языка, но недавно я наткнулся на эту старую статью Джоэла, в которой объясняется его происхождение и то, как многие неправильно его поняли — по крайней мере, теперь я могу понять причину этого! joelonsoftware.com/articles/Wrong.html — Mathias

Почему это не функция синтаксической подсветки вместо венгерской нотации? Почему бы IDE просто не выделять курсивом идентификаторы, относящиеся к интерфейсам, если так важно различать классы и интерфейсы. ненавижу ставить»«или» м» перед полями, «C» перед классами и т. д. Хуже того, это побуждает программистов писать очень плохие API, такие как:

вместо более разумного:

Даже авторы общих классов .NET попали в эту ловушку. Имя класса НИКОГДА не должно быть именем интерфейса, в котором удалена только буква «I». Имя класса всегда должно сообщать пользователю, чем класс отличается от других возможных реализаций интерфейса(ов). Я голосую за отказ от глупого «я» только по этой причине.

Кроме того, когда я использую intellisense, я хочу сгруппировать вещи по функциональным областям, а не по классу или интерфейсу. Я никогда не думаю: «Мне нужен интерфейс, а не класс». Я всегда думаю: «Мне нужно что-то, что делает X».

ответ дан 17 мар ’14, в 17:03

Я рад, что я не единственный, кто видит это таким образом. Похоже, я в меньшинстве. 4 года спустя я все еще поражен тем, как много читателей клянутся, что «это упрощает идентификацию интерфейса», и полностью упускают суть. — i3ensays

Это действительно хороший момент при проектировании интерфейса с учетом расширяемости, но другой вариант использования абстрагирования интерфейсов (C# и Java) предназначен исключительно для разъединения, позволяющего имитировать зависимости, где никакая другая конкретная реализация интерфейса не использовалась. явно «предназначен для». Так MyReallySpecificBusinessComponent и IMyReallySpecificBusinessComponent было бы хорошо. Но определенно нет List . — СтюартЛК

На самом деле я считаю полезным избегать конфликтов имен, я мог бы, например, создать конкретный класс с именем Fred, который реализует IFred.

Конфликтов имен можно избежать, используя осмысленные/полезные имена. Например, Fred расширяет Person, реализует возможности Living, Breathing и другие. Без дополнительного контекста я не могу сказать наверняка, но если Фред является объектом домена/модели, интерфейс для него, вероятно, излишен. — i3ensays

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

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

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

этот класс обслуживания наследуется от Dog и реализует IDataService

Я все еще не совсем отвечаю на ваш вопрос, но I полезен, потому что вы получаете коллизии имен между пространством имен, классом и интерфейсом.

так что мы получаем

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

ответ дан 04 мар ’17, в 23:03

+1 — вообще говоря, я думаю, что соглашения об именах указывают на слабость языка разработки (и, вероятно, здесь дело обстоит именно так), но, тем не менее, важно иметь возможность избегать этих коллизий, когда вы хотите использовать внедрение зависимостей и имитировать объекты-сотрудники . На самом деле нет альтернативы соглашению об именах, когда вы создаете интерфейсы для объектов предметной области. — Джефф Стернал

/shrug Я использую его и для сервисов WCF. У меня есть IServeData и ICanMakePayments для двух моих сервисов. — рукав моря

@JeffSternal Я думаю, вы, возможно, применяете анти-шаблон «каждый объект должен иметь интерфейс». Вероятно, вам не следует создавать интерфейсы для объектов предметной области; они часто являются ожидаемой частью вашего общедоступного API. — i3ensays

Если вы рассмотрите два «афоризма о передовом опыте»,

между ними есть конфликт. Вопрос в том, когда ясность становится шумом?

Для меня более шумно (но одинаково четко) писать Person person = new PersonImpl() чем IPerson person = new Person() .

ответ дан 23 дек ’11, 12:12

Или еще лучше: Person p = new TallPerson(); но в моем случае Person вряд ли будет интерфейсом. Вместо этого это базовый тип, который расширяет TallPerson, то есть абстрактный тип. В любом случае «интерфейс» Person подразумевается его общедоступным API. Я презираю FooImpl() не меньше, чем IFoo. — i3ensays

Либо так, либо добавить «Impl» в реализацию интерфейса (аргх). У меня нет проблем с «Я», это самое простое и понятное имя для интерфейса.

Я не согласен с предложением «Impl» — это был бы напрасный шум, как и префикс «I». Реализация должна быть названа с учетом ее реализации. Например, интерфейс «База данных» может быть реализован с помощью «RelationalDatabase» и «InMemoryDatabase». — i3ensays

Это соглашение, вы не обязаны ему следовать, если оно вам не нравится. — Отавио Десио

Дело не в том, что мне это нравится. Я сомневаюсь в его ценности. Мне нравится придерживаться условностей не только ради следования за стаей. Я хочу понять рациональное. Будем надеяться, что кто-то сможет сформулировать это рациональное решение помимо «это позволяет вам узнать, что это интерфейс» (что делает IDE с красивыми значками). — i3ensays

Конвенция «Я» кажется старой условностью, которая не актуальна сегодня. Текущий редактор кода дает много информации об используемом типе, поэтому утверждать, что легче идентифицировать интерфейс, все равно что просить, чтобы пространство имен имело префикс «N», потому что вы хотите быть уверены, что не перепутаете его с конкретный класс (префикс с «C»?).

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

Возьмем, к примеру, генератор документации C#: ему все равно. если ваш интерфейс не имеет префикса «I», вы все равно увидите свой интерфейс в части интерфейса вашей документации. Вы действительно думаете, что наличие префикса «I» для всех ваших интерфейсов в разделе интерфейса вашей документации является важной информацией и поможет вам лучше идентифицировать интерфейсы?

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

Класс должен иметь единственную причину существования. Ни в коем случае не следует помещать второстепенные роли в базовый класс. Например:

Первый — это файл конфигурации, специализированный на Xml, второй — на Yaml. Они тоже одноразовые, но это не так важно. Вы не создали эти два класса из-за разных процессов утилизации.

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

Проблема начинается, когда вы создаете классы, у которых есть несколько причин существования:

Даже если XmlConfigurationFile и YamlConfigurationFile были бы интерфейсами, это все равно указывает на плохой дизайн. Как ваш файл конфигурации может быть Xml и Yaml одновременно?

Если вы прочитаете приведенные примеры (здесь и в других местах), люди всегда изо всех сил пытаются найти хороший пример того, когда I-префикс имеет значение. Один из ответов здесь:

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

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

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

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