Jump to content

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


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

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

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

Архитектура, основанная на интерфейсах, может использоваться, когда третьи лица – или даже отдельные группы внутри одной организации – разрабатывают дополнительные компоненты или плагины для установленной системы. Кодовая база Eclipse IDE является примером программирования на основе интерфейса. Поставщикам подключаемых модулей Eclipse просто нужно разработать компоненты, которые удовлетворяют интерфейсу, указанному поставщиком родительского приложения, Eclipse Foundation. Действительно, в Eclipse даже оригинальные компоненты, такие как инструменты разработки Java, сами по себе являются плагинами. Это похоже на то, как производитель мобильного телефона указывает интерфейс мобильного зарядного устройства (расположение контактов, ожидаемое напряжение постоянного тока и т. д.), а производитель и третьи стороны создают свои собственные зарядные устройства для мобильных телефонов, соответствующие этой стандартной спецификации интерфейса.

Эволюция программного обеспечения в интерфейсном программировании

[ редактировать ]

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

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

Оба эти подхода использовались на платформе Java.

Проектирование по договору

[ редактировать ]

Издатель интерфейсов обычно обещает, что не будет менять интерфейс в новых «минорных» версиях ПО, а разработчик, реализуя интерфейс, подразумевает, что он реализовал как минимум необходимые части интерфейса без каких-либо отклонений. Таким образом, интерфейс можно рассматривать как «контрактное соглашение» между поставщиком и потребителем интерфейса. Если этот контракт более формально документирован как спецификация программного обеспечения, это пример проектирования по контракту . Однако проектирование по контракту само по себе не требует использования интерфейсов для всех компонентов.

См. также

[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: e36720f62e6dd8ae136ec9ae07bced37__1707855540
URL1:https://arc.ask3.ru/arc/aa/e3/37/e36720f62e6dd8ae136ec9ae07bced37.html
Заголовок, (Title) документа по адресу, URL1:
Interface-based programming - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)