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

Интерфейсы

Определение интерфейсов

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

Определение интерфейса

Для определения интерфейса используется ключевое слово interface . Как правило, названия интерфейсов в C# начинаются с заглавной буквы I , например, IComparable, IEnumerable (так называемая венгерская нотация), однако это не обязательное требование, а больше стиль программирования.

Что может определять интерфейс? В целом интерфейсы могут определять следующие сущности:

Статические поля и константы (начиная с версии C# 8.0)

Однако интерфейсы не могут определять нестатические переменные. Например, простейший интерфейс, который определяет все эти компоненты:

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

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

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

Еще один момент в объявлении интерфейса: если его члены — методы и свойства не имеют модификаторов доступа, но фактически по умолчанию доступ public , так как цель интерфейса — определение функционала для реализации его классом. Это касается также и констант и статических переменных, которые в классах и структурах по умолчанию имееют модификатор private. В интерфейсах же они имеют по умолчанию модификатор public. И например, мы могли бы обратиться к константе minSpeed и переменной maxSpeed интерфейса IMovable:

Но также, начиная с версии C# 8.0, мы можем явно указывать модификаторы доступа у компонентов интерфейса:

Начиная с версии C# 8.0 интерфейсы поддерживают реализацию методов и свойств по умолчанию. Это значит, что мы можем определить в интерфейсах полноценные методы и свойства, которые имеют реализацию как в обычных классах и структурах. Например, определим реализацию метода Move по умолчанию:

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

Стоит отметить, что если интерфейс имеет приватные методы и свойства (то есть с модификатором private), то они должны иметь реализацию по умолчанию. То же самое относится к любым статическим методам и свойствам (не обязательно приватным):

Модификаторы доступа интерфейсов

Как и классы, интерфейсы по умолчанию имеют уровень доступа internal , то есть такой интерфейс доступен только в рамках текущего проекта. Но с помощью модификатора public мы можем сделать интерфейс общедоступным:

Стоит отметить, что в Visual Studio есть специальный компонент для добавления нового интерфейса в отдельном файле. Для добавления интерфейса в проект можно нажать правой кнопкой мыши на проект и в появившемся контекстном меню выбрать Add -> New Item. и в диалоговом окне добавления нового компонента выбрать пункт Interface :

5 уровней UX: как создавать удобные интерфейсы

Денис Нарижный, руководитель «Студия F1» и создатель сервиса AskUsers.ru, написал специально для «Нетологии» колонку о том, как разрабатывать понятные продукты и интерфейсы и проверять свои идеи на каждом отдельном этапе.

Это история не про вдохновение и видение. А о методе, который помогает разрабатывать эффективные системы и понятный дизайн. Просто, понятно, пошагово.

Модель была создана в начале 2000-х Джесси Гарреттом и получила название «5 уровней UX». Простая для понимания и предельно наглядная, она прекрасно иллюстрирует процесс разработки любой системы и помогает определиться с тем, что именно нужно вашим пользователям.

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

Диаграмма Гарретта

Базой для модели стала диаграмма, при помощи которой Гарретт сумел показать связь между разными подходами к дизайну в рамках проектирования пользовательского опыта.

Двигаясь от абстрактного к конкретному и от концепции к реализации, Гарретт выделил пять уровней.

В зависимости от назначения системы: ориентации на действие или на предоставление информации — основные задачи могут описываться по-разному. Но общий смысл от этого не меняется.

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

#1 Уровень стратегии

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

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

Отвечаем на вопросы:

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

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

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

Какие тесты проводить:

• исследование этнографии,
• интервью, онлайн-опросы и фокус-группы,
• концепт-тесты.

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

#2 Уровень возможностей

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

Отвечаем на вопросы:

• Какие функции нужны для решения пользовательских задач?
• Какую функциональность предлагают конкуренты?
• Какой контент нужен пользователям?

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

Какие тесты проводить:

• концепт-тесты,
• тест «Сортировка карточек»,
• интервью, онлайн-опросы и фокус-группы.

Результат работы на уровне возможностей — полное описание функционала продукта, составленное с учетом реальных потребностей пользователей.

#3 Уровень структуры

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

Отвечаем на вопросы:

• Как помочь пользователю решить задачу за минимальное время и количество шагов?
• Понятна ли архитектура проекта пользователям?
• Соответствует ли дизайн ожиданиям пользователей?
• Можно ли безболезненно изменять архитектуру при необходимости?

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

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

Какие тесты проводить:

• юзабилити-исследование,
• A/B и Side by Side тесты,
• тест привлекательности,
• тестирование методом совместного дизайна,
• интервью, онлайн-опросы, фокус-группы,
• сортировка карточек.

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

#4 Уровень компоновки

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

Отвечаем на вопросы:

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

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

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

• юзабилити-исследование,
• A/B тестирование,
• Side by Side тесты,
• тест привлекательности,
• совместный дизайн,
• интервью, онлайн-опросы, фокус-группы,
• сортировка карточек.

Результат — проверенный на реальных пользователей прототип продукта.

#5 Уровень поверхности

Финальный уровень — визуальное оформление прототипа: дизайн, типографика, верстка. На этом уровне вся абстракция конкретизируется до уровня готового продукта.

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

• Удобен ли наш интерфейс для пользователей?
• Решает ли он задачи, описанные на первых уровнях?
• Соответствует ли он тем функциям, которые в него должны быть заложены?
• Помогает ли дизайн пользователю?
• Решает ли визуальное оформление задачи, которые были заложены при проектировании пользовательского опыта?

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

Результат работы на этом уровне — полностью готовый к дальнейшей работе продукт: интерфейс, сайт, приложение, веб-сервис или любая другая система.

Но это еще не конец

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

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

IT1205: Программирование Java SE

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

Описание интерфейсов

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

В заголовке интерфейса имени интерфейса предшествует ключевое слово interface . Также в заголовке интерфейса может содержаться следующая информация:

• видимость или модификатор доступа;
• любой интерфейс, который расширяется.

Тело интерфейса может содержать объявления членов, а именно:

• объявления констант;
• объявления прототипов методов;
• объявления вложенных классов и интерфейсов.

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

Объявления членов возможны в произвольном порядке в теле интерфейса. Поскольку интерфейсы предназначены для реализации их классами, их члены неявно общедоступны, а модификатор доступа public опускается. Интерфейсы с пустыми телами используются как маркеры для обозначения классов, имеющих определенное свойство или поведение. Такие интерфейсы также называются интерфейсами способности (ability interfaces). Java API предоставляет несколько примеров таких интерфейсов-маркеров:

Объявления прототипов методов

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

В примере 6.9 объявлены два интерфейса: IStack в строке (1) и ISafeStrack . в строке (5). Эти интерфейсы рассматриваются в последующих подразделах.

Пример 6.9. Интерфейсы

Реализация интерфейсов

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

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

В примере 6.9 класс StackImpl реализует интерфейс IStack . Одновременно определяя имя интерфейса в операторе implements в заголовке класса в строке (2) и предоставляя реализацию для методов в интерфейсе в (3) и (4). Изменение общедоступной ( public ) видимости этих методов приведет к ошибке компиляции, так как это действие сужает уровень доступа членов.

Класс может выбрать для реализации только некоторые методы из его интерфейсов (т.е. предоставить частичную реализацию своих интерфейсов). Класс затем должен быть объявлен как абстрактный ( abstract ). Обратите внимание, что методы интерфейса не могут быть объявлены как static , потому что они содержат контракт, выполняемый объектами класса, реализующего интерфейс. Методы интерфейса всегда реализуются как методы экземпляра (instance methods).

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

Расширение интерфейсов

Интерфейс может расширять другие интерфейсы с помощью оператора extends В отличие от расширения классов интерфейс может расширять несколько интерфейсов. Интерфейсы, расширяемые интерфейсом (напрямую или косвенно), называются суперинтерфейсами. Напротив, интерфейс является подынтерфейсом своего суперинтерфейса. Поскольку интерфейсы определяют новые ссылочные типы, суперинтерфейсы и подынтерфейсы также называются супертипами и подтипами соответственно.

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

В примере 6.9 показан вариант множественного наследования в Java. В нем интерфейс ISafeStack расширяет интерфейс IStack в строке (5). Класс SafeStacklmpl одновременно расширяет класс Stacklmpl и реализует интерфейс ISafeStack в строке (6). И реализация, и иерархия наследования интерфейса для классов и интерфейсов, рассмотренная в примере 6.9, показана на рис. 6.3.

В UML интерфейс имеет сходство с классом. Единственный способ, чтобы их различать, заключается в использовании фразы interface , как показано на рис. 6.3. Наследование интерфейсов показывается подобно наследованию реализации, но пунктирной стрелкой наследования. Размышляя в терминах типов, каждый ссылочный тип в Java является подтипом типа Object . Это означает, что каждый тип интерфейс также является подтипом типа Object . Рис. 6.3 дополнен стрелками наследования чтобы показать отношение между подтипом и супертипом.

Стоит обратить внимание на то, как класс SafeStackImpl реализует интерфейс ISafeStack : он наследует реализации методов push() и рор() из своего суперкласса StackImpl и предоставляет свою собственную реализацию методов isFull() и isEmpty() из интерфейса ISafeStack . Интерфейс ISafeStack наследует два прототипа методов из суперинтерфейса IStack . Все его методы реализуются классом SafeStackImpl . Класс SafeStackImpl неявно реализует интерфейс iStack : он реализует интерфейс ISafeStack , который наследует от интерфейса iStack . Это легко видно из ромбовидной формы иерархии наследования на рис. 6.3. Существует только одна единичная реализация наследования в классе SafeStackImpl .

Рис. 6.З. Отношение наследования

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

1. Линейная иерархия наследования реализации между классами: класс расширяет другой класс (подклассы — суперклассы).
2. Иерархия множественного наследования между интерфейсами: интерфейсы расширяют другие интерфейсы (подынтерфейсы — суперинтерфейсы).
3. Иерархия множественного наследования между интерфейсами и классами: класс реализует интерфейсы.

Хотя интерфейсы не могут порождать объекты, ссылки интерфейсных типов можно объявить. Ссылки на объекты класса могут быть присвоены ссылкам супертипов класса. В примере 6.9 создается объект класса SafeStackImpl в методе main() класса StackUser в строке (9). Значение объектной ссылки присваивается всем ссылка типа супертипов объекта, которые используются для управления им.

Константы в интерфейсах

В интерфейсе также можно объявить именованные константы. Такие константы описываются посредством объявлений полей и считаются общедоступными ( public ) и статическими ( static ) и неизменяемыми ( final ). Модификаторы доступа обычно опускаются при объявлении.

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

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

Интерфейс (программирование)

Интерфе́йс (от англ. interface — поверхность раздела, перегородка) — совокупность средств и методов взаимодействия между элементами системы.

В зависимости от контекста, понятие применимо как к отдельному элементу (интерфейс элемента), так и к связкам элементов (интерфейс сопряжения элементов).

• вожжи — главный элемент интерфейса между лошадью и кучером (вожжи — интерфейс системы «лошадь — кучер»). Или же вожжи — интерфейс (управления) лошади;
• руль, педали газа и тормоза, ручка КПП — интерфейс (управления) автомобиля, или же интерфейс системы «водитель — автомобиль». Для автомеханика же интерфейсными элементами являются совсем другие устройства — щуп уровня масла, например;
• электрические вилка и розетка — являются интерфейсом энергоснабжения большинства бытовых приборов;
• клавиатура и мышь — являются интерфейсом компьютера в контексте «пользователь — ЭВМ»;
• адрес электронной почты — является коммуникационным интерфейсом пользователя интернет;
• английский язык — основной коммуникационный интерфейс между пользователями интернет;
• протокол передачи данных — часть интерфейса клиент-серверной архитектуры;
• предоставление резюме и собеседование — части системы «процесс трудоустройства»;

Этот термин используется практически во всех областях науки и техники. Его значение относится к любому сопряжению взаимодействующих сущностей. Под интерфейсом понимают не только устройства, но и правила (протокол) взаимодействия этих устройств.

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

Интерфейсы в вычислительной технике

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

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

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

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

• Интерфейс командной строки: инструкции компьютеру даются путём ввода с клавиатуры текстовых строк (команд).
• Графический интерфейс пользователя: программные функции представляются графическими элементами экрана.
• Диалоговый интерфейс
• Естественно-языковой интерфейс: пользователь «разговаривает» с программой на родном ему языке.

Физический интерфейс

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

• Сетевой интерфейс
• Шлюз (телекоммуникации) — устройство, соединяющее локальную сеть с более крупной, например, Интернетом
• Шина (компьютер)
• Нейро-компьютерный интерфейс (англ.brain-computer interface ): отвечает за обмен между нейронами и электронным устройством при помощи специальных имплантированных электродов.

Интерфейсы в программировании

• Интерфейс функции
• Интерфейс программирования приложений (API): набор стандартных библиотечных методов, который программист может использовать для доступа к функциональности другой программы.
• Вызов удалённых процедур
• COM-интерфейс
• Интерфейс (ООП)

Интерфейс (ООП)

Интерфейс (иногда так же контракт, interface) в объектно-ориентированной парадигме программирования — частный случай абстрактного класса.

Содержание

Общее понятие интерфейса и сравнение с абстрактным классом

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

Предназначение интерфейсов

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

Интерфейсы выполняют всё ту же роль абстрактных элементов, то есть заставляют реализующие классы реализовывать описанные абстрактные методы. По этому интерфейсы реализовывают (не расширяют/наследуют), а именно реализовывают в классах. Разумеется, создать объект интерфейса нельзя. Использовать напрямую абстрактные классы и интерфейсы нельзя, их надо расширять/наследовать и реализовывать.

Основные моменты касательно интерфейсов

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

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

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

Языки использующие интерфейсы

Интерфейсы присущи современным ленивым объектно-ориентированным языкам программирования таким как Java и C#. В том же хардкорном C++ интерфейсов нет так как там для этого есть абстрактные классы и разрешённое множественное наследование классов.

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

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

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

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

Интерфейс и абстрактный класс

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