Войти
. Программирование на основе интерфейса, также известное как архитектура на основе интерфейса, является архитектурным шаблоном для реализации модульного программирования на уровне компонента на языке объектно-ориентированного программирования, который не имеет модульной системы. Примером такого языка является Java, который (по состоянию на 2015 год) не имеет модульной системы на уровне компонентов. Java имеет систему пакетов, но программные компоненты Java обычно состоят из нескольких пакетов Java - и в любом случае программирование интерфейса может обеспечить преимущества по сравнению с простым использованием пакетов Java, даже если компонент состоит только из одного пакета Java..
Программирование на основе интерфейса определяет приложение как набор компонентов, в котором вызовы интерфейса прикладного программирования (API) между компонентами могут выполняться только через абстрактные интерфейсы, а не конкретные классы. Экземпляры классов обычно получают через другие интерфейсы с использованием таких методов, как шаблон Factory.
. Утверждается, что он увеличивает модульность приложения и, следовательно, его ремонтопригодность. Однако следует соблюдать некоторую осторожность - простое разделение приложения на произвольные компоненты, взаимодействующие через интерфейсы, само по себе не гарантирует низкого сцепления или высокого сцепления, двух других атрибутов, которые обычно считаются ключевыми для ремонтопригодность.
Архитектура на основе интерфейса может использоваться, когда третьи стороны - или даже отдельные группы в рамках одной организации - разрабатывают дополнительные компоненты или плагины для установленной системы. Кодовая база Eclipse IDE является примером программирования на основе интерфейса. Поставщикам подключаемых модулей Eclipse просто нужно разработать компоненты, удовлетворяющие интерфейсу, указанному поставщиком родительского приложения, Eclipse Foundation. Действительно, в Eclipse даже исходные компоненты, такие как Java Development Tools, сами по себе являются плагинами. Это в некоторой степени похоже на то, как производитель мобильных телефонов указывает интерфейс мобильного зарядного устройства (расположение контактов, ожидаемое напряжение постоянного тока и т. Д.), И производитель и третьи стороны создают свои собственные зарядные устройства для мобильных телефонов. которые соответствуют этой стандартной спецификации интерфейса.
Использование интерфейсов для совместной работы разрозненных команд поднимает вопрос о том, как происходят изменения интерфейса в программировании на основе интерфейсов. Проблема в том, что при изменении интерфейса, например при добавлении нового метода старый код, написанный для реализации интерфейса, больше не будет компилироваться, а в случае динамически загружаемых или связанных подключаемых модулей либо не будет загружаться, либо связываться, либо давать сбой во время выполнения. Существует два основных подхода к решению этой проблемы:
Оба этих подхода использовались в платформе Java.
Издатель интерфейсов обычно обещает, что они не будут изменять интерфейс в новых «минорных» версиях программного обеспечения, а разработчик, реализуя интерфейс, подразумевает, что они реализовали хотя бы необходимые части интерфейса без каких-либо отклонений. Таким образом, интерфейс можно рассматривать как «договорное соглашение» между поставщиком и потребителем интерфейса. Если этот контракт оформлен более формально как спецификация программного обеспечения, это пример проектирования по контракту. Однако разработка по контракту сама по себе не требует использования интерфейсов для всех компонентов.
