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

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

  • автор:

CA1715: идентификаторы должны иметь правильные префиксы

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

По умолчанию это правило проверяет только видимые извне интерфейсы, типы и методы, но это поведение можно настроить.

Описание правила

По соглашению имена некоторых программных элементов начинаются с определенного префикса.

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

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

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

Настройка кода для анализа

Используйте следующие параметры, чтобы указать части базы кода, к которым будет применяться это правило.

  • Включение определенных контактных зон API
  • Параметры типа с одним символом

Эти параметры можно настроить только для этого правила, для всех правил, к которым она применяется, или для всех правил в этой категории (именование), к которым она применяется. Дополнительные сведения см. в статье Параметры конфигурации правила качества кода.

Включение определенных контактных зон API

Вы можете настроить, для каких частей базы кода следует выполнять это правило в зависимости от их доступности. Например, чтобы указать, что правило должно выполняться только для закрытой контактной зоны API, добавьте следующую пару «ключ-значение» в файл EDITORCONFIG в своем проекте:

dotnet_code_quality.CAXXXX.api_surface = private, internal 

Параметры типа с одним символом

Вы можете указать, следует ли исключать из этого правила параметры типа из одного символа. Например, чтобы указать, что это правило не должно анализировать параметры типа из одного символа, добавьте одну из следующих пар «ключ-значение» в файл editorconfig в проекте:

# Package version 2.9.0 and later dotnet_code_quality.CA1715.exclude_single_letter_type_parameters = true # Package version 2.6.3 and earlier dotnet_code_quality.CA2007.allow_single_letter_type_parameters = true 

Это правило никогда не срабатывает для параметра типа с именем T , например Collection .

Устранение нарушений

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

Когда лучше отключить предупреждения

Для этого правила отключать вывод предупреждений не следует.

Пример именования интерфейса

В следующем фрагменте кода показан неверно именованный интерфейс:

' Violates this rule Public Interface Book ReadOnly Property Title() As String Sub Read() End Interface 
// Violation. public interface Book < string Title < get; >void Read(); > 

Следующий фрагмент кода устраняет предыдущее нарушение, добавляя к интерфейсу префикс «I»:

// Fixes the violation by prefixing the interface with 'I'. public interface IBook < string Title < get; >void Read(); > 
' Fixes the violation by prefixing the interface with 'I' Public Interface IBook ReadOnly Property Title() As String Sub Read() End Interface 

Пример именования параметров типа

В следующем фрагменте кода показан неверно именованный параметр универсального типа:

' Violates this rule Public Class Collection(Of Item) End Class 

// Violation. public class Collection

Следующий фрагмент кода устраняет предыдущее нарушение, добавляя к параметру универсального типа префикс «T»:

// Fixes the violation by prefixing the generic type parameter with ‘T’. public class Collection

' Fixes the violation by prefixing the generic type parameter with 'T' Public Class Collection(Of TItem) End Class 

Совместная работа с нами на GitHub

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

Поясните за именование классов и интерфейсов в Java

Я тут решил попробовать новый для себя ЯП и запилить рогалик.

В процессе работы быстро понял, что не плохо было бы иметь простенький текстовый GUI.
Сейчас у меня есть три класса:

TextBuffer — сюда пишутся символы и их цвет
Window — имеет TextBuffer, пишет в него, обрабатывает ввод
WindowManager — управляет окнами, передает ввод активному окну, рисует окна

В чем проблема — я хочу добавить ModalWindow. Для этого, мне нужен интерфейс, который будет реализован классами Window и ModalWindow.

Я начал читать про именования классов и интерфейсов:

Имена классов должны быть существительными. В смешанном регистре первой заглавной буквой (PascalCase). Старайтесь именовать классы коротко и ясно. Используйте целые слова, избегайте сокращений (Кроме случаев, когда сокращение гораздо распространеннее, чем полная версия, как URL или HTML).

Имена интерфейсов пишутся так же, как и имена классов.

WTF? Что значит так же?

Я так и не понял, как в моем случае нужно именовать классы и интерфейс?

#1
12:10, 21 июня 2018

public interface OperateCar < .

#2
7:57, 22 июня 2018

Чётко же написано, что классы и интерфейсы именуются одинаково. В твоём случае можно, например так:

public interface Window < . >public class StandardWindow implements Window < . >public class ModalWindow implements Window
#3
9:00, 22 июня 2018

обычно имя интерфейса начинается с I, но это просто хорошая практика, а не догма, а в остальном никаких отличий

#4
9:07, 22 июня 2018

Madware
>венгерская нотация
>2018
>хорошая практика
.

#5
9:41, 22 июня 2018

Maltakreuz
это не венгерская нотация

  • Имбирная Ведьмочка
  • Участник

#6
10:15, 22 июня 2018

Madware
> обычно имя интерфейса начинается с I, но это просто хорошая практика, а не
> догма, а в остальном никаких отличий
Это в крестах, а в джаве - классы и интерфейсы называются одинаково, потому что для внешнего наблюдателя класс функционирует точно так же, как и интерфейс.
Плюс заставляет программиста, вместо того, чтобы тупо лепить I куда попало, реально задумываться - а что же такого уникального в данной конкретной реализации? А может, в ней нет ничего уникального, и лучше вообще не рождать никаких интерфейсов?

Bizunow
А что именно должен делать твой интерфейс?

#7
13:12, 22 июня 2018

Delfigamer
В шарпе скорее. Потому что в крестах нет такой вещи как интерфейс.

Да, действительно, в джаве без I, почему-то я подумал что у нее с C# идентичный подход

#8
13:18, 22 июня 2018

Потому что в крестах нет такой вещи как интерфейс.

Есть. Просто они в хеадер файлах прописаны самими Микрософт.
То есть как правило , программист часто не пользуется интерфейсами. Потому что за него это уже сделала сама Микрософт.
А вот когда прогер хочет привязать например Directx 11 к другому ЯП, то приходится возится с интерфейсами самому.

Главное отличие класса от интерфейса — в том, что класс состоит из интерфейса и реализации.

Любой класс всегда неявно объявляет свой интерфейс — то, что доступно при использовании класса извне.
Если у нас есть класс Ключ и у него публичный метод Открыть, который вызывает приватные методы Вставить, Повернуть и Вынуть, то интерфейс класса Ключ состоит из метода Открыть. Когда мы унаследуем какой-то класс от класса Ключ, он унаследует этот интерфейс.

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

#9
13:31, 22 июня 2018

Ziltop
>
> Главное отличие класса от интерфейса — в том, что класс состоит из интерфейса и
> реализации.
Только, уже с JAVA8 интерфейс состоит тоже из реализации и объявление .

  • Имбирная Ведьмочка
  • Участник

#10
14:08, 22 июня 2018

Madware
> Потому что в крестах нет такой вещи как интерфейс.
Чего в крестах нет - это специального синтаксиса для описания интерфейсов, потому что в крестах интерфейс является частным случаем абстрактного класса.

Ziltop
> Главное отличие класса от интерфейса — в том, что класс состоит из интерфейса и реализации.
Это другое значение слова "интерфейс" - в котором оно используется в аббревиатуре "API".

#11
14:27, 22 июня 2018

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

#12
14:39, 22 июня 2018

Delfigamer
> А что именно должен делать твой интерфейс?
У меня есть два метода - draw и handleInput, они должны быть в любом окне. Вот для этого я и решил использовать интерфейс.

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

Интерфейс

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

Хотите узнать больше? В общем случае под словом интерфейс понимают правила и рамки взаимодействия двух произвольных объектов. В рамках компьютерной терминологии такими объектами обычно выступают люди, оборудование, программное обеспечение или его компоненты, но этот термин применим и далеко за ее пределами.

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

Уже догадались? Да, это я так неспеша плавно подводил разговор к объектно-ориентированному программированию. Термин интерфейс широко применяется и в нем. Как не трудно предположить, в роли объектов в этом случае выступают как сами классы, так и их экземпляры (которые, впрочем, тоже принято называть словом объект).

В общем случае интерфейсом класса выступает совокупность его public методов и переменных, то есть доступных для обращения из других частей приложения. Этот факт вполне логичен - именно благодаря им и осуществляется взаимодействие класса (или его объекта) с "внешним миром". Но не все так просто, особенно с точки зрения шаблонов проектирования, немаловажную роль в взаимодействии классов и объектов играет абстракция. Хочется обратить внимание, что формально имеется ввиду даже не сами методы, а их заголовки, то есть название, набор получаемых переменных и тип возвращаемого значения (этот набор данных принято также принято называть интерфейсом методов или функций), само тело метода (реализация) в данном случае не важно.

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

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

Самым наглядным языком программирования для демонстрации описания интерфейсов я считаю Java (хотя можно было бы выбрать и C#, PHP или практически любой другой по вкусу). В теории все просто:

  • Ключевое слово interface обозначает описание интерфейса;
  • За ним следует название конкретного интерфейса, которое впоследствии можно будет использовать в коде при его упоминании (некоторые программисты на правах традиции начинают названия интерфейсов с заглавной буквы I, мне в свое время даже пытались объяснить зачем так надо делать, но аргументы не показались мне достаточно весомыми);
  • Далее идет тело интерфейса, в котором перечисляются все заголовки методов, которые должны быть в классе, реализующем данный интерфейс (никакой реализации!);
  • Впоследствии приписав к заголовку любого класса ключевое слово implements с последующим указанием названия интерфейса, можно обязать этот класс реализовать указанные в описания интерфейса методы. Существует небольшое исключение для абстрактных классов (то есть классов,для которых не может быть создан объект, обозначаются ключевым словом abstract ), они могут и не реализовать все методы интерфейса, но тогда эта обязанность будет переложена на их наследников.

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

Небольшое примечание: сами интерфейсы и методы в их теле по-умолчанию обладают свойствами abstract и public , так что повторно указывать эти ключевые слова не нужно.

На практике же это выглядит это примерно следующим образом:

// описание интерфейса interface Renderable  // обязуем реализовать метод draw public void draw(); > // конкретная реализация интерфейса class SomeText implements Renderable  string text; public SomeText(string str)  this.text=str; > public void draw()  // вынуждены подчиниться и реализовать System.out.println(this.text); > > // класс-клиент class Render  public Render(Renderable obj)  // можно быть уверенным, что // метод draw реализован obj.draw(); /* в качестве альтернативы можно было бы написать как-то так: if(obj instanceof Renderable)obj.draw(); то есть проверить реализован ли интерфейс вместо использования его названия в роли типа данных */ > 

В данном примере ситуация тривиальна: класс-клиент Render умеет лишь визуализировать классы, которые он получает в конструктор, вызывая у них метод draw . Для обеспечения такой возможности описан интерфейс Renderable , который реализуется в классе SomeText . Хоть класс Render ничего и не знает о том, какой именно класс ему подсунут, благодаря интерфейсу он сможет вывести на экран любой объект, корректно реализующий наш интерфейс, в том числе и SomeText .

Как я уже упоминал: альтернативой такому подходу является использование полиморфизма и наследования. Такой подход более распространен в других языках программирования, например C++, но пример я приведу все равно на Java, основываясь на предыдущем примере, чтобы читателям было проще сравнивать.

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

// теперь используем абстрактный класс abstract class Renderable  // реализуем метод draw public void draw()  System.out.println("Вывод на экран недоступен!"); > > // реализация интерфейса (на этот раз неформального) class SomeText extends Renderable  // на этот раз используем extends (наследование) // вместо implements string text; public SomeText(string str)  this.text=str; > public void draw()  // переопределяем метод draw // но могли этого и не делать, тогда // использовался бы метод из Renderable System.out.println(this.text); > > // класс-клиент class Render  public Render(Renderable obj)  // можно быть уверенным, что // метод draw реализован obj.draw(); /* на этот раз так как в крайнем случае в крайнем случае вызовется хотябы метод из класса Renderable */ > 

Минимальные изменения - суть та же. Сразу хочу отметить, что этот процесс так прост только в Java, в других языках программирования понадобилось бы использование дополнительных модификаторов для метода draw (например в C#: virtual или abstract в классе-потомке и override в классе-наследнике, это необходимо для обеспечения возможности их переопределения).

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

С маленькой или с Большой

Такая мелочь, как применения заглавных букв может быть весьма важной. Для английского языка. Статья будет особенно полезна тем, кто занимается разработкой продуктов на английском.
(Кстати, кто еще не знает, «вуз» пишется маленькими буковками.)

image

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

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

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

EDISON Software Development Centre

Подробнее о методологии тестирования, которую мы используем на проектах в EDISON Software Development Centre.

Title case против Sentence case

В большинстве сегодняшних продуктов и сайтов используются два типа капитализации слов:

  • Title case: Каждое слово пишется с прописной буквы. Это Пример Title Case.
  • Sentence case: Первое слово пишется с прописной буквы. Это пример sentence case.

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

image

Подпись слева — предупреждение iOS: Заголовок в title case
Подпись справа — предупреждение Android: Заголовок в sentence case

Неважно, в команде ли вы Apple или Google, iPhone или Android, хорошо бы понимать с чем вы связываетесь когда используете title case или sentence case. Давайте внимательнее посмотрим на каждый стиль.

Что хорошего в title case?

Для начала давайте посмотрим почему вам может захотеться использовать title case.

Больше симметрии
Некоторые люди полагают, что title case смотрится лучше, потому что он более симметричный. До тех пор пока ваши фразы остаются короткими, title case создает приятный визуальный ритм вашим словам:

image

В симметрии заключена красота и иногда этого достаточно для дизайнера или автора, чтобы отдать предпочтение title case, а не sentence case.

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

image

Заметили насколько больше заголовок слева выступает, чем тот что справа? Чем больше он выделяется, тем больше вероятность что кто-то его действительно прочтет.

Больше «серьёзности»
Как и слово «серьёзность», title case придает вашим словам ощущение формальности и важности. Такие сайты как The New York Times или USA.gov используют в основном title case. Это Профессионально. Серьезно. Авторитетно.

Использование title case подобно надеванию костюма на слова. Для определенных брендов вы можете захотеть чтобы ваши слова выглядели так, будто бы они имеют ввиду бизнес. Если вы занимаетесь бизнесом, связанным с безопасностью например, title case вероятнее даст почувствовать профессионализм и надежность по сравнению с sentence case.

image

Представьте, что вы руководитель компании. Какой вариант ощущается более профессиональным?

Что хорошего в sentence case?

Далее, давайте посмотрим почему вам может захотеться использовать sentence case в своих продуктах или на сайте.

Легче читать
Основная причина использования sentence case в том, что его легче читать, особенно когда текст становится длинным. Вы Можете Себе Представить Как Бы Сложно Было Постоянно Читать Длинные Заголовки в Title Case?

Вот поэтому меня сбивает с толку скриншот ниже из руководящих принципов Apple (Если вам интересно, это тот же самый скриншот, что я уже использовал ранее).

image

Подпись: Мне больно читать заголовок этого предупреждения

Легче определить
Согласно первому автору Google UX, Sue Factor, одной из главных причин почему Google решил использовать sentence case была легкость объяснения дизайнерам и инженерам. В интерфейсе продукта не всегда понятно, что можно рассматривать как «заголовок». Имя вкладки это заголовок? А что насчет флажков настроек? Или сообщения о подтверждении?

Помимо этого, существуют многочисленные способы использования title case. Например, вы будете капитализировать предлоги «от» или «через»? Что насчет артиклей «the» или «an»? В зависимости от того, каким руководящим принципам вы следуете, конкретные правила для title case могут отличаться. Ниже приведены правила title case согласно Apple.

image

Подпись: ok, быстрый тест. Нужно ли писать слово «about» с большой буквы?

Если у вас есть разные люди, работающие над вашим продуктом или сайтом, они могут просто забыть обо всех правилах при использовании title case. Вы можете избежать этого замешательства просто используя везде sentence case. Существует всего один способ написания sentence case, его сложнее испортить.

Дружелюбнее
Совсем как title case смотрится более формально и серьезно, sentence case выглядит более повседневным и дружелюбным. Я автор в Dropbox и мы специально используем sentence case поскольку хотим чтобы наш бренд воспринимался естественно и достижимо. Мы считаем, что голос нашего продукта отделяет наш от конкурентов и использование sentence case для нас это один из способов поддерживать этот голос.

image

Подпись: Вы чувствуете любовь?

Легче обнаружить имена собственные
В итоге, sentence case также облегчает чтение фраз с именами собственными. Имена собственные это те слова, которые вы всегда пишите с заглавной буквы — ваше имя, New York или Microsoft.

Сегодня многие компании дают своим фичам и продуктам такие описательные названия как «Входящие» (Inbox) или «Календарь» (Calendar) в противовес причудливым именам «Искра» (Spark) или «Чудесный» (Fantastical). Если вы используете title case на всех кнопках, то становится неясным являются ли некоторые вещи именами собственными или нет и это может влиять на удобство использования.

image

Подпись слева — “Календарь” относится к моему приложению Календарь или к любому приложению календарь? Подпись справа — Да, первый вариант добавит это в мое приложение Календарь.

Другие регистры?

Title case и sentence case являются двумя самыми популярными стилями капитализации, но они безусловно не единственные возможные.

Наглядные пример: На Windows Phone 8 Microsoft использовало много текста с нижним регистром в своем интерфейсе, даже для заголовков и кнопок.

image

Подпись — избыток нижнего регистра на Windows Phone 8

Затем существует GIPHY, один из моих любимых сайтов. Их сайт использует верхний регистр повсеместно, что имеет смысл для них, поскольку текст мем обычно написан всеми заглавными буквами.

image

Подпись GIPHY: CAPS РУЛИТ

Делая выводы

Оба, title case и sentence case имеют свои преимущества. Какое бы направление вы не выбрали, просто убедитесь, что вы принимаете обоснованное решение, которое имеет смысл для вашего бренда. Самое плохое, что вы можете сделать это не иметь совсем никаких стандартов, что в итоге приведёт к несоответствиям, которые будет проблемно исправлять позже.

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

Дело закрыто?

А что о вас? Вы фанаты sentence case или title case? Нижнего или верхнего? Или вы просто мятежники, играющие по своим собственным правилам?

В любом случае, мне интересно, что вы думаете. Поделитесь своими мыслями или вопросами в комментариях ниже.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *