Объясните по-простому, на пальцах, зачем и для чего нужны интерфейсы (Java)? Все эти заумные книжные определения и формулировки, ясности совсем не прибавляют.
Отслеживать
51k 83 83 золотых знака 262 262 серебряных знака 500 500 бронзовых знаков
задан 15 авг 2012 в 15:51
760 2 2 золотых знака 8 8 серебряных знаков 22 22 бронзовых знака
Вопросом на вопрос: вы программируете без использования интерфейсов?
15 авг 2012 в 15:56
если трудно объяснить словами, можно на примере простого исходника.
15 авг 2012 в 16:22
16 ответов 16
Сортировка: Сброс на вариант по умолчанию
Общее определение: Интерфейс — это совокупность методов и правил взаимодействия элементов системы. Другими словами, интерфейс определяет как элементы будут взаимодействовать между собой.
- Интерфейс двери — наличие ручки;
- Интерфейс автомобиля — наличие руля, педалей, рычага коробки передач;
- Интерфейс дискового телефона — трубка + дисковый набиратель номера.
Когда вы используете эти «объекты», вы уверены в том, что вы сможете использовать их подобным образом. Благодаря тому, что вы знакомы с их интерфейсом.
#2 Основы IT для тестировщика / Виды интерфейсов / Что такое GUI, API, CLI?
В программировании что-то похожее. Почему графическую часть программы часто называют интерфейсом? Потому, что она определяет каким образом вы сможете использовать основной функционал, заложенный в программе.
«Интерфейс определяет каким образом мы можем использовать объект» — перенесем эту мысль в плоскость программирования.
Предположим, у вас в программе есть следующие типы:
// несколько базовых интерфейсов, они пустые, // т.к. их наполнение на данный момент не существенно interface Rul <> interface Pedal <> interface Kpp <> // интерфейс описывает взаимодействие с автомобилем — т.е. его интерфейс // предоставляет другим объектам доступ к рулю и педалям // (по сути этот интерфейс соответствует автомобилю с коробкой автоматом) interface Car < Rul getRul(); Pedal[] getPedali(); >// этот интерфейс расширяет базовый // и предоставляет доступ еще и к коробке передач interface CarWithKPP extends Car < Kpp getKpp(); >// а здесь у нас сам автомобиль // реализации методов опущены т.к. не существенно class SomeCar implements CarWithKpp
а сейчас посмотрим, как можно пользоваться тем, что у нас есть:
// создаем новый объект SomeCar instance = new SomeCar(); // делаем какие-то действия над объектом testAction1(instance); testAction2(instance);
Как видите, используем мы их одинаково, но суть кроется в реализации методов:
void testAction1(CarWithKpp c) < c.getRul(); // можно c.getPedali(); // можно c.getKpp(); // можно >void testAction2(Car c) < c.getRul(); // можно c.getPedali(); // можно c.getKpp(); // нельзя, ошибка компиляции. этот метод не определен в интерфейсе Car >
С одной стороны, тот факт, что SomeCar наследует интерфейс CarWithKpp (а посредством последнего еще и Car ), позволяет нам использовать его для работы с методами testAction1, testAction2 . Интерфейсы, которые реализованы (имплементированы) в классе SomeCar — предоставляют доступ к правильному его использованию. А еще использование интерфейса в сигнатуре метода гарантирует, что вы получите именно тот тип, который вам нужен.
Что такое API?
Обратная сторона медали состоит в том, что интерфейс накладывает ограничения на использование класса. Примером этому является то, что в методе testAction2 получить доступ к методу getKpp уже невозможно. Таким образом, можно скрыть методы и свойства, которые объявлены в интерфейсе CarWithKpp , а также методы, объявленные в классе SomeCar (если их нет в интерфейсе). Оба метода могут использовать только тот набор «средств», которые им доступны (это определяется интерфейсом).
Отслеживать
28.4k 10 10 золотых знаков 57 57 серебряных знаков 118 118 бронзовых знаков
ответ дан 15 авг 2012 в 21:38
6,252 16 16 серебряных знаков 21 21 бронзовый знак
Kpp — это шикарно 🙂
16 авг 2012 в 8:04
ну так наверно автомат/неавтомат
16 авг 2012 в 8:06
По простому говорите? Ну ок, правда сейчас тут начнут плеваться всякие товарищи типо гуру 🙂
Интерфейс — это возможность взглянуть на класс как на объект немного другого типа.
Поясню: ну как бы название говорит за это. Объект в ООП это некая сущность имеющая свой набор методов и работы с ним — методы назовем условно «воротами», а интерфейс это «дверь» в этих «воротах» — немножко другой способ обращения с тем же самым объектом. Так что если забыть про «ворота» то это кажется другим объектом. Ключевое слово здесь кажется.
Пример: есть объект стол, у которого есть методы работы с ним: как то есть поесть сидя за ним, накрыть на нем хавчик, поставить, собрать, отпилить ножки и проч. Но этот же объект стол можно рассматривать как интерфейс мебель (на языке ООП это называется класс типа стол реализующий интерфейс типа мебель: class Table implements Furniture . Понятно, что не на всякой мебели можно поесть или отпилить ножку, но что уж точно так это то что мебель можно поставить и собрать.
Теперь для чего все это нужно. Опять же пример с мебелью — если скажем есть объект стул, который также реализует интерфейс мебель, то и со стулом и со столом можно обращаться одинаково — в этом и состоит смысл интерфейса — в унификации работы с разнотипными объектами.
P.S. Кстати, любимый вопрос интервьюеров на собеседовании: что имеет более высокий уровень абстракции — класс, абстрактный класс или интерфейс? Правильный ответ — интерфейс
Отслеживать
ответ дан 15 авг 2012 в 16:09
81k 7 7 золотых знаков 72 72 серебряных знака 153 153 бронзовых знака
Прочитал. Критикую. Пример с воротами — неудачный, со столом — плохой. Так как интерфейсы это больше как «набор правил/ рычагов воздействия на обьекты» одного типа, а у тебя примеры больше подходят к extened. У класса мебель могут быть свойтва — тип — дерево, пластик; высота, вес, цена, стул — наследник на 4х ножках, а у интерфейса для работы с мебелью методы типа — погрузить в машину, выкинуть, продать. Отсюда интерфейс — это розетка, за которой не видно как идет ток, какого он напряжения, как там провода перепутаны, но к нему всегда можно подключить любую технику
15 авг 2012 в 17:10
15 авг 2012 в 17:39
15 авг 2012 в 19:29
15 авг 2012 в 19:55
. а если принять таблеточку LSD — получится IoC контейнер.
15 авг 2012 в 20:22
Вам может показаться странным, но это именно то, что отличает человека от животного — использование интерфейсов вместо классов. Вы наверняка помните классический опыт с обезьяной, которую приучили гасить огонь водой из ведёрка; а потом поставили ведёрко на плот посреди бассейна, но обезьяна всё равно бегала по мостику на плот и черпала воду из ведёрка, вместо того, чтобы черпать воду прямо из бассейна. То есть обезьянка использовала класс Вода-в-Ведёрке вместо интерфейса Вода (и даже больше, скажу по секрету: вместо интерфейса Средство-для-Тушения).
Когда мы мыслим классами — уподобляемся животным. Люди мыслят (и программируют) интерфейсами.
Отслеживать
ответ дан 1 окт 2014 в 5:33
249 2 2 серебряных знака 6 6 бронзовых знаков
Это правильный подход (я про остальную часть статьи на хабре, а не мыслях о различии людей и животных).
1 окт 2014 в 9:42
Понимание интерфейсов придёт со временем. Сколько не читай, сколько не объясняй, Вы Сами должны понять ту гибкость, тот масштаб действий, которые они предоставляют программисту. Пытайтесь их использовать. Библиотека классов Java предоставляет интерфейсы для реализации. Попробуйте их изучить, возможно это поможет Вам уловить всю мощь которую предоставляет программирование с использованием интерфейсов.
Отслеживать
ответ дан 15 авг 2012 в 16:12
ivan milyutkin ivan milyutkin
255 1 1 серебряный знак 5 5 бронзовых знаков
Интерфейс — это описание того, что может и должен уметь делать объект класса, который реализует этот интерфейс.
Не будем оригинальны и возьмем для примера дверь.
Что обычный человек может сделать с дверью? Открыть и закрыть.
Соответственно интерфейс для нее будет такой:
interface Door
А теперь следите за руками. Объекту человек нужно пройти через дверь. Важно ему какая дверь перед ним дверь, деревянная, железная, с окошком, открывается она на себя или от себя, а может вообще сдвигается в бок? Нет, не важно.
Ему важно, чтобы ее в принципе можно было открыть.
По этому, в классе «Человек» мы принимаем в метод «Пройти через дверь» не какую-то конкретную дверь, а в принципе «Дверь», потому что знаем, что у нее есть метод «Открыть».
class Human < public void goThruDoor(Door door)< if(door.isClosed())< if(!door.open())< throw new Exception(«дверь не открывается :(«); >> goForward(); door.close(); > >
Соответственно ниже пример двух объектов, реализующие интерфейс «Дверь» и которые можно передать «Человеку» в метод «Пройти через дверь», но реализующие разную логику для метола «Открыть».
class WoodenDoor implements Door < private boolean closed = false; public boolean isClosed()< return closed; >public boolean open() < if(!closed) return false; closed = false; return true; >public boolean close() < if(closed) return false; closed = true; return true; >> class LockedDoor implements Door < private boolean locked = true; private boolean closed = false; public boolean isClosed()< return closed; >public boolean open() < if(locked||!close) return false; closed = false; return true; >public boolean close() < if(closed) return false; closed = true; return true; >>
Отслеживать
ответ дан 9 сен 2017 в 10:24
13.9k 4 4 золотых знака 33 33 серебряных знака 51 51 бронзовый знак
Интерфейсом** объекта мы назовём набор операций (методов), которые он может совершать или которые можно совершать над ним. Например, интерфейс числа 3 называется, собственно, «Число» и включает в себя набор операций сложения, вычитания, умножения и деления.
Реализовать этот интерфейс может любое количество типов/классов, например, типы ЦелоеЧисло, ВещественноеЧисло, КомплексноеЧисло, а также такие неочевидные типы как Интервал или Полином. В то же время, один и тот же тип может реализовать более чем один интерфейс. Так, ЦелоеЧисло кроме интерфейса Число может реализовать интерфейс Перечислимый – для этого в классе ЦелоеЧисло будет необходимо всего лишь доопределить операции «следующий» и «предыдущий».
Отслеживать
ответ дан 15 авг 2012 в 15:57
12.4k 1 1 золотой знак 19 19 серебряных знаков 43 43 бронзовых знака
А где размещён при этом интерфейс Перечислимый ? В Число ?
28 ноя 2013 в 13:16
Представьте себе группу друзей. Все они люди и имеют свои особенности, профессии(кто-то шахтер, кто-то бармен и т.д.). Тут братва пришла в бар посидеть выпить пивка.
А бар такой — если вы хотите быть клиентами бара — не вопрос реализуйте наш интерфейс «Клиент», и вот вам свод действий которые вы должны реализовать являясь клиентом: Купить пивко, сесть за стол, выпить пивко, заплатить счет. Все друзья разные, кто-то врач, кто-то сантехник, кто-то без руки, кто-то с татухой на лбу(странная компашка знаю)), но когда они приходят в бар — все они «клиенты» и обязаны реализовать интерфейс «Клиент» с его методами. Да, каждый из них реализует, интерфейс по своему — кто-то даст на чай, когда будет оплачивать счет, кто-то разобьет бутылку об лоб, когда будет пить пивко ну и т.д.(это уже полиморфизм), но все они клиенты в данный момент и сотрудники бара взаимодействуют с ними как с клиентами, а не Васей(шахтером), Петей(алкоголиком). и.д.
В общем интерфейсы нужны, что бы связать группу не связанных объектов, которые обязаны реализовать поведение того интерфейса, что бы можно было взаимодействовать с ними через этот общий интерфейс.
Отслеживать
ответ дан 25 ноя 2019 в 13:59
Влад Леонидов Влад Леонидов
527 3 3 серебряных знака 12 12 бронзовых знаков
Объясню без деталей.
Допустим, мы создали Framework, который определяет, совершил ли пользователь double-click по экрану.
Там мы определили функцию: что_делать_если_пользователь_кликнул_2_раза_по_экрану() .
Но мы решаем не определять поведение этой функции сами, а предоставить эту реализацию программисту, использующему наш фреймворк. Предоставление этой реализации можно сделать через механизм интерфейсов.
Функцию: что_делать_если_пользователь_кликнул_2_раза_по_экрану() засовываем в интерфейс.
И, таким образом, сам момент двойного клика по экрану определяет наш фреймворк, а вот что делать (рисовать звездочки на экране, запустить проигрывание музыки и т.д.) после этого события решает программист, который реализует наш интерфейс.
Польза: программисту не надо думать, как словить double-click . За ним только реализация ответа на это событие.
Отслеживать
1,745 9 9 золотых знаков 19 19 серебряных знаков 28 28 бронзовых знаков
ответ дан 9 сен 2017 в 8:38
473 7 7 серебряных знаков 17 17 бронзовых знаков
«зачем и для чего»:
1) Взаимодействие с окружающим миром. Программы пишет не один человек, они состоят не из одного класса и зачастую не из одного пакета и модуля. И суть программы в том, что код разных авторов, разных модулей взаимодействует между собой. Самый простой пример: вы пользуетесь сторонними библиотеками.
Вы нашли нужный вам класс, подключили библиотеку, которая его содержит и вызываете оттуда методы. В какой-то момент автор библиотеки решил изменить свой код, разве это редкость? Исправить выявленные баги, улучшить, расширить функционал. И это может оказаться для вас глубокой неожиданностью: ваш-то код завязан на его код! И ваш код внезапно ломается.
Чтобы такого не происходило, чтобы чужой открытый код мог использоваться сторонними разработчиками без неожиданностей, придумали интерфейсы. Интерфейс — это объявление функционала. Имплементация классом интерфейса — это гарантия реализации функционала.
Если класс имплементирует некоторый интерфейс, то он обещает, что в нем есть объявленные в интерфейсе методы, они принимают объявленные параметры и возвращает объявленное значение. У вас может возникнуть вопрос: но ведь интерфейсы — это тоже код и его так же, как и класс, можно изменить. Можно. Но на практике это происходит крайне редко, интерфейс — это заявленный контракт и мы понимаем, что наш интерфейс, если он открыт, может использоваться не только нами.
2) В Java в качестве ссылки на переменную может выступать интерфейс. Например, уместен следующий метод:
public void letsIterateABit(Iterable something) < //Iterable — это интерфейс, у которого есть метод iterator(). //какой-то код something.iterator(); //еще какой-то код >
В этот метод можно передать любой объект которые имплементирует интерфейс Iterable. Конечно, и вызывать в этом случае мы у него сможем только те методы, которые есть в интерфейсе. Но иногда этого более чем достаточно!
3) Интерфейсы позволяют реализовывать инверсию зависимостей. Если вы разобрались в первых двух пунктах, но не разобрались в этом — у вас все хорошо, вернитесь перечитать статью через полгода.
Источник: ru.stackoverflow.com
Интерфейсы, взаимодействие и изменение программ и данных
Аннотация: Рассмотрены основы интеграции и преобразования разноязыковых программ и данных, методы изменения (реинженерия, реверсная инженерия и рефакторинг) компонентов и систем, дана характеристика стандарта о независимости типов и структур данных от языков программирования, а также рассмотрены принципы взаимодействия неоднородных компонентов в современных промежуточных средах
В данной лекции рассматриваются базовые понятия программной инженерии — интерфейсы, средства их представления, взаимодействие разноязыковых программ и преобразование типов данных . Представлены подходы к обеспечению интерфейсов программ, записанных в разных языках программирования (ЯП), методы преобразования неэквивалентных типов данных при взаимодействии модулей и программ.
Определены общие задачи неоднородности ЯП, платформ и сред, влияющих на установление связей между разноязыковыми программами, сформулированы пути их решения. Рассмотрены рекомендации стандарта ISO/IEC 11404-1996 по обеспечению независимых от современных ЯП типов данных.
Рассмотрены подходы к преобразованию форматов данных и данных в БД , а также методы изменения (эволюции) программ.
8.1. Задачи интерфейса при разработке программ
Общее определение. Интерфейс — это связь двух отдельных сущностей. Виды интерфейсов: языковые, программные, аппаратные, пользовательские, цифровые и т. п. Программный ( API ) и/или аппаратный интерфейс (port) — это способы преобразования входных/выходных данных во время объединения компьютера с периферийным оборудованием. В ЯП — это программа или часть программы, в которой определяются константы , переменные, параметры и структуры данных для передачи другим.
В программировании термин интерфейс олицетворяет собой набор операций, обеспечивающих определение видов услуг и способов их получения от программного объекта, предоставляющего эти услуги. На начальном этапе программирования в роли интерфейса выступают операторы обращения к ее процедурам и функциям программ через формальные параметры.
Программы, процедуры и функции записывались в одном ЯП. Операторы обращения включали имена вызываемых объектов (процедур и функций) и список фактических параметров, задающих значения формальным параметрам и получаемым результатам. Последовательность и число формальных параметров соответствовало фактическим параметрам. Выполнение функции в среде программы на одном ЯП не вызывало проблем, так как типы данных параметров совпадали.
В случае, когда один из элементов ( программа , процедура или функция ) записаны на разных ЯП и, кроме того, если они располагаются на разных компьютерах, то возникают проблемы неоднородности типов данных в этих ЯП, структур памяти платформ компьютеров и операционных сред, где они выполняются. Понятие интерфейса, как самостоятельного объекта, сформировалось в связи со сборкой или объединением разноязыковых программ и модулей в монолитную систему на больших ЭВМ ( mainframes ) [8.1, 8.2].
Рис. 8.1. Схема вызова модулей А и В из С через интерфейсы А’и B’
Интерфейс играл роль посредника между вызываемым и вызывающим модулями. В нем давалось описание формальных и фактических параметров, производилась проверка соответствия передаваемых параметров (количества и порядка расположения), а также их типов данных.
Если типы данных параметров оказывались не релевантными (например, передается целое, а результат функции — вещественное или наоборот), то производилось прямое и обратное их преобразование с учетом структуры памяти компьютеров. На рис. 8.1 приведена схема программы 
, в которой содержатся два вызова — 
и 
с параметрами, которые через интерфейсные модули-посредники 
и 
производят преобразование данных и их передачу модулям 
и 
. После выполнения и результаты преобразуются обратно к виду программы 
.
8.1.1. Интерфейс в ООП и в современных средах
Интерфейс в ООП.В ООП главным элементом является класс, включающий множество объектов с одинаковыми свойствами, операциями и отношениями. Класс имеет внутреннее (реализацию) и внешнее представление — интерфейс (табл. 8.1).
- публичные, доступные всем клиентам:
- защищенные, доступные классу п подклассу:
- приватные, доступные классу.
Интерфейс содержит множество операций, описывающих его поведение. Класс может поддерживать несколько интерфейсов, каждый из которых содержит операции и сигналы, используются для задания услуг класса или программного компонента. Интерфейс именует множество операций или определяет их сигнатуру и результирующие действия.
Если интерфейс реализуется с помощью класса, то он наследует все его операции. Одни и те же операции могут появляться в различных интерфейсах. Если их сигнатуры совпадают, то они задают одну и ту же операцию, соответствующую поведению системы. Класс может реализовывать другой класс через интерфейс.
Операции и сигналы могут быть связаны отношениями обобщения. Интерфейс-потомок включает в себя все операции и сигналы своих предков и может добавлять собственные путем наследования всех операций прямого предка, т.е. его реализацию можно рассматривать как наследование поведения.
Новое толкование интерфейса объектов дано в работе П.Вегнера [8.3], который сформулировал парадигму перехода от алгоритмоввычислений к взаимодействию объектов. Суть этой парадигмы заключалась в том, что вычисление и взаимодействие объектов рассматривались как две ортогональные концепции. Взаимодействие — это некоторое действие ( 
), но не вычисление, а сообщение — не алгоритм, а действие, ответ на которое зависит от последовательности операций ( 
), влияющих на состоянии разделенной ( 
, 
) памяти локальной программы (рис. 8.3). Операции интерфейса ( 
и 
) относятся к классу неалгоритмических и обеспечивают взаимодействие объектов через сообщения.
увеличить изображение
Рис. 8.3. Интерфейс взаимодействия через операции интерфейса (по Вегнеру)
Вегнер рассматривает модель взаимодействия, как обобщение машины Тьюринга — распределенной интерактивной модели взаимодействия объектов с входными (input) и выходными (output) действиями и возможностью продвижения в ней потенциально бесконечного входного потока (запросов, пакетов) в заданном интервале времени.
Дальнейшим развитием идеи взаимодействия, основанного на действиях, является язык AL (Action language), обеспечиывющий вызовов процедур (локальных или распределенных) с разверткой каждого вызова в программу [8.4], состоящую из операторов действий. Программа из вызовов процедур рассматривается в AL как ограниченное множество конечных программ, взаимодействующих со средой, в которую они погружаются.
Интерфейс в современных средах и сетях.Появление разных компьютеров и их объединение в локальные и глобальные сети привело к уточнению понятия интерфейса как удаленного вызова (сообщения) программ, расположенных в разных узлах сети или среды и получающих входные данные из сообщений.
Сети строятся на основе стандартной семиуровневой модели открытых систем OSI (Open Systems Interconnection) [8.5]. Объекты уровней в этой модели связываются между собой по горизонтали и вертикали. Запросы от приложений поступают на уровень представления данных для их кодирования (перекодирования) к виду используемой в приложении платформы. Открытые системы предоставляют любым приложениям разного рода услуги: управление удаленными объектами, обслуживание очередей и запросов, обработка интерфейсов и т. п.
Доступ к услугам осуществляется с помощью разных механизмов:
- вызова удаленных процедур RPC (Remote Procedure Call) в системах ОNС SUN, OSF DSE [8.5, 8.6];
- связывания распределенных объектов и документов в системе DCOM [8.7];
- языка описания интерфейса IDL ( Interface Definition Language) и брокера объектных запросов — ORB ( Object Request Broker ) в системе CОRBA [8.8];
- вызова RMI (Remote Methods Invocation) в системе JAVA [8.9, 8.10] и др.
RPC- вызов задает интерфейс удаленным программам в языках высокого или низкого уровней. Язык высокого уровня служит для задания в RPC-вызове параметров удаленной процедуры, которые передаются ей через сетевое сообщение. Язык низкого уровня позволяет указывать более подробную информацию удаленной процедуре: тип протокола, размер буфера данных и т. п.
Взаимосвязь процесса с удаленно расположенным от него другим процессом (например, сервером) на другом компьютере выполняет протокол UDP или TCP/IP, который передает параметры в stub — интерфейсе клиента stub -серверу для выполнения удаленной процедуры.
Механизм посылки запроса в системе CORBA базируется на описании запроса в языке IDL для доступа к удаленному методу/функции через протокол IIOP или GIOP . Брокер ORB передает запрос генератору, затем посылает stub / skeleton серверу, выполняющему интерфейс средствами объектного сервиса (Common Object Services) или общими средствами (Common Facilities). Так как брокер реализован в разных распределенных системах: CORBA, COM, SOM , Nextstep и др. [8.2], то он обеспечивает взаимодействие объектов в разных сетевых средах.
Вызов метода RMI в системе JAVA выполняет виртуальная машина (virtual machine), которая интерпретирует byte-коды вызванной программы, созданные разными системами программирования ЯП (JAVA, Pascal, С++) на разных компьютерах и средах. Функции RMI аналогичны брокеру ORB .
8.1.2. Интерфейс в среде клиента и сервера
В распределенной среде реализуется два способа связывания: на уровне ЯП через интерфейсы прикладного программирования и компиляторов IDL, генерирующих клиентские и серверные Stab. Интерфейсы определяются в языках IDL или APL , динамический интерфейс от объектаклиента к объектусервера и обратно выполняет брокер ORB . Интерфейсы имеют отдельную реализацию на ЯП и доступны разноязыковым программам. Компиляторы с IDL как часть промежуточного слоя сами реализуют связывание с ЯП через интерфейс клиента и сервера, заданного в том же ЯП [8.8, 8.11-8.13].
Интерфейс в IDL или в API включает описание формальных и фактических параметров программ, их типов и порядка задания операций передачи параметров и результатов при их взаимодействии. Это описание есть не что иное, как спецификация интерфейсного посредника двух разноязыковых программ (аналогично, как на рис. 8.1), которые взаимодействуют друг с другом через механизм вызова интерфейсных функций или посредников двух типов программ (клиент и сервер), выполняемых на разных процессах.
В функции интерфейсного посредника клиента входят:
- подготовка внешних параметров клиента для обращения к сервису сервера,
- посылка параметров серверу и его запуск в целях получения результата или сведений об ошибке.
Общие функции интерфейсного посредника сервера состоят в следующем:
- получение сообщения от клиента, запуск удаленной процедуры, вычисление результата и подготовка (кодирование или перекодирование) данных в формате клиента;- возврат результата клиенту через параметры сообщения и уничтожение удаленной процедуры и др.
Описание интерфейсного посредника не зависит от ЯП взаимодействующих объектов и в целом одинаково для всех вызывающих и вызываемых объектов. Посредник описывается в языке спецификации интерфейса IDL.
Интерфейсные посредники задают связь между клиентом и сервером ( stub для клиента и skeleton для сервера). Их описания отображаются в те ЯП, в которых представлены соответствующие им объекты или компоненты. Эти интерфейсы используются в системах CORBA, DCOM, LAVA и др. Они предоставляют всевозможные сервисы разработки и выполнения приложений в распределенной среде.
Системные сервисы подключаются к приложению с помощью брокера. Брокер обеспечивает интероперабельность компонентов и объектов при переходе из одной среды другую.
Под интероперабельностью понимается способность совместного, согласованного взаимодействия разнородных компонентов системы для решения определенной задачи.
К средствам обеспечения интероперабельности и передачи данных между разными средами и платформами относится, например, стандартный механизм связи между JAVA и C/C++ компонентами, основанный на применении концепции Java Native Interface ( JNI ), реализованной как средство обращения к функциям из JAVA- классов и библиотек, разработанных на других языках.
Эти средства включает в себя анализ JAVA-классов в целях поиска прототипов обращений к функциям, реализованных на языках C/C++, и генерацию заголовочных файлов для использования их при компиляции C/C++ программ. В средстве JAVA классу известно, что в нем содержится обращение не к JAVA-методу (он называется и для загрузки необходимых C/C++ библиотек добавляется вызов функции), ориентируется именно на такую связь. Данная схема действует в одном направлении — от JAVA к C/C++ и только для такой комбинации ЯП.
Еще вариант реализации аналогичной задачи предлагает технология Bridge2Java,которая обеспечивает обращение из JAVA- классов к COM-компонентам. В этих целях генерируется оболочка для COM-компонента, который включает прокси-класс, обеспечивает необходимое преобразование данных средствами стандартной библиотеки преобразований типов. Данная схема не требует изменений в исходном Java-классе и COM-компоненты могут быть написаны в разных языках.
Механизм интероперабельности реализован также на платформе . Net с помощью языка CLR (Common Language Runtime). В этот язык транслируются коды, написанные в разных ЯП (C#, Visual Basic, C++, Jscript). CLR разрешает не только интегрировать компоненты, разработанные в разных ЯП, а и использовать библиотеку стандартных классов независимо от языка реализации.
Такой подход позволяет реализовать доступ к компонентам, которые были разработаны раньше без ориентации на платформу . Net, например к COM-компонентам. Для этого используются стандартные средства генерации оболочки для COM-компонента, с помощью которой он представляется как . Net-компонент. При такой схеме реализуются все виды связей и для любых ЯП данной среды.
Источник: intuit.ru
Разбираемся с понятиями «Интерфейс» и «Протокол»
Понятия «Протокол» и «Интерфейс» неразрывно связаны друг с другом, именно поэтому их так часто путают не только новички, но и опытные специалисты в области IT-технологий. Эти термины используются всегда, когда речь идёт о передаче данных. Причём, не важно, какой обмен данными имеется в виду, это может быть обмен между приложениями, устройствами, между человеком и компьютером – во всех этих случаях мы имеем дело с «интерфейсом» и «протоколом». Однако не многие могут дать внятный ответ на вопрос: «в чём разница между этими понятиями?», попросту путают эти термины или считают их синонимами. В данной статье мы постараемся раз и навсегда внести ясность в этот вопрос.
Для начала дадим определения.
Интерфейс – совокупность аппаратных и программных средств, необходимых для взаимодействия с программой, устройством, функцией и т.д.
Протокол — набор правил, соглашений, сигналов, сообщений и процедур, регламентирующий взаимодействие между сопрягаемыми объектами.
Сложно? На самом деле всё проще, чем кажется. Давайте разбираться!
Что такое интерфейс
Возьмём простой пример: обмен информацией между двумя людьми. Допустим, вам нужно передать сообщение своему другу из другого города. Вы можете это сделать многими способами: отправить ему письмо обычной почтой, почтовым голубем или воспользоваться электронной, можете написать в социальной сети, позвонить по телефону или Skype. Всё это – интерфейсы. Необходимо запомнить, что интерфейс всегда отвечает на вопросы: «Как?», «Каким способом?».
Понятие «интерфейс» также используется, когда речь идёт о взаимодействии компьютерной программы или устройства с человеком. Можно услышать: «программа имеет дружелюбный интерфейс» или «пылесос с беспроводным интерфейсом». В этих случая так же речь идёт о способах взаимодействия.
Например, телевизором можно управлять с помощью пульта дистанционного управления или с помощью кнопок. Это его интерфейсы. Для подключения внешних устройств телевизоры имеют интерфейсы USB, DVI, HDMI и другие.
Если мы говорим про интерфейс компьютерной программы, то это тоже способ обмена данными: можно работать в программе пользуясь удобной графической оболочкой, а можно с помощью командной строки.
Как вы понимаете, чтобы организовать обмен данными по какому-либо интерфейсу, необходимо чтобы все участники взаимодействия обладали этим интерфейсом: для того, чтобы написать другу по электронной почте – нужно, чтобы у него был e-mail, а для того чтобы управлять беспроводным пылесосом, нужен пульт.
Интерфейс может содержать в себе другие интерфейсы. Когда мы говорим про передачу сообщения обычной почтой, мы говорим про один интерфейс. Но на самом деле наше письмо может доставляться поездом, самолётом, автотранспортом – это тоже интерфейсы, но они «скрыты» от нас, мы никак не участвуем в их выборе, поэтому для нас это один интерфейс «Почта России».
Что такое протокол
На этом же примере разберёмся, что же такое протокол. Вы можете отправить письмо в виде текста на русском языке или на китайском, можете нарисовать рисунок или послать аудиозапись (если это электронное письмо). Это и есть протоколы передачи – правила, с помощью которых кодируется информация, которую вы собираетесь передать. Протоколы могут быть наложены друг на друга.
Например, вы можете написать письмо, пользуясь шифром, который знаете только вы и ваш друг, а символы в нём использовать из кириллицы – то есть вы как бы наложите на одни правила обмена информацией другие правила более высокого уровня. Адресат расшифрует ваше послание, если конечно он владеет этими правилами.
На конверте письма нужно указать адрес получателя – это тоже часть протокола – правила, необходимые для передачи сообщения, но не нужные для его расшифровки. Поэтому, в общем случае при передаче данных может использоваться несколько протоколов. Каждая строка адреса получателя – это директива для разных сегментов почтовой сети. Например, для почтового отделения, откуда письмо начнёт свой путь, не важны улица, дом и номер квартиры получателя, важен только город, куда нужно направить письмо.
В цифровой технике всё происходит аналогично. Когда мы отправляем сообщение пользователю в социальной сети, оно проходит огромное количество промежуточных звеньев от браузера вашего компьютера до браузера компьютера адресата – это сетевые карты, роутеры, шлюзы и т.д. Поскольку всё это оборудование связано разными интерфейсами, наше исходное сообщение «обрастает» большим количеством дополнительной информации на каждом сетевом уровне.
Заключение
Итак, в данной статье мы разобрались, что интерфейс – это способ обмена информацией, а протокол – это совокупность правил, которые необходимо соблюдать при передаче данных по выбранному интерфейсу. При обмене информацией может использоваться несколько интерфейсов, каждый из которых использует свой протокол передачи. При этом каждый протокол как бы оборачивает данные в свою коробку. Получается своеобразная «матрёшка» из данных, которая потом «разбирается» обратно до исходного сообщения, которое и получает адресат.
На этом всё! Надеемся, что было интересно! До встречи на страницах LAZY SMART .
Чтобы не пропустить новую статью, вступай в нашу группу Вконтакте , а также подписывайся на наш канал YouTube .
Источник: lazysmart.ru