Уже не первый раз сталкиваюсь с понятием интерфейс. Полез в википедию, и слегка запутался..
 Как я понял бывают com-интерфейсы, API-интерфейсы... А бывают вообще другие интерфейсы. Чем они отличаются между собой?
 Читая информацию по данной теме, я понял, что интерфейсы представляет ни что иное как класс, только бывает на уровне операционной системы, а бывает на уровне кода внитри программы, верно?

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

Т.е. если я хочу использовать типа данных double или int - нужен интерфейс, если хочу использовать класс - нужен интерфейс... и тд ?

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

 Вы же сами сказали, что:



Я понимаю, что это не логично. Вот я и переспросил..

Это сообщение отредактировал(а) hoz - 28.6.2013, 18:01

Да и написал к этому, что в C++ вместо интерфейсов для тех же целей используются классы, содержащие лишь чисто абстрактные функции-члены. При чём тут вообще double или int?

Почитай хотя бы вот это:
http://ru.wikipedia.org/wiki/Интерфейс_(об...ограммирование)

Это сообщение отредактировал(а) NightmareZ - 28.6.2013, 17:59

Да я об этом читал:

Странная вещь. Если всё это реализуется, значит всё-таки данная объектная подсистема и есть интерфейс.. По логике.


Я это и всё что там друг на друга ссылается касаемо данной темы щяс и читаю. А про " double или int " я специально уточнил. Так как я Вам цитату приводил выше, странный ответ был. Хотел убедится. Я с Си перешёл на С++, привыкаю. Диковато..

Я верно понимаю взаимосвязь API и COM-компонента?
COM-интерфейсы тоже взаимодействуют между собой посредством API ?
Тут сказано:

А тут, сказано, что:


Получается, что как компонент с компонентом, так и другое программное приложение взаимодействует с компонентом посредством API ?

Это сообщение отредактировал(а) hoz - 28.6.2013, 19:36

Вы неверно понимаете смысл слов, который употребляете.
Поэтому ответить что-то вразумительное - проблематично. 

COM-интерфейсы не взаимодействуют между собой посредством API =)
Взаимодействуют компоненты, посредством COM-интерфейса, который и являецца API (Application Programming Interface) в данном контексте

Добавлено через 2 минуты и 25 секунд

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

 Дело в том, что я так сразу и понял. Но COM-интерфейс и API это же не одно и тоже ? Я просто изучаю этот вопрос, и судя по тому, что читаю, можно подумать, что это тоже самое...
 Ведь COM-интерфейсы уже используются сравнительно давно, и появились рвньше ежели API. Если всё "связывалось" как нужно, зачем тогда изобретать велосипед и внедрять API?


Ну это я понял, тут логично.

Это сообщение отредактировал(а) hoz - 29.6.2013, 12:41

Не путайте теплое с мягким. В чем-то это близкие понятия, но вам надо просто понять что такое API - Это просто набор функций, предоставляемых тем или иным компонентом, частью ОС и т.п. для того, что бы им можно было управлять. Т.е. API - это обобщенное понятие.
Соответственно если идти снизу вверх, то мы можем видеть, что разные слои вычислительной системы предоставляют свой API для взаимодействия с ними.
BIOS - свой API, очень низкоуровневый
Дальше подсистема Драйверов предоставляет свой API для всей остальной ОС
Сама ОС предоставляет API уже для программ, которые работают под её управлением
Какая-то библиотека программная (например Qt) предоставит вам свой API, что бы вы могли писать программы с её помощью.
А COM это просто такой несколько извращенный (абстрагированный) способ выполнить нужную вам задачу, не задумываясь о том, кто же её будет выполнять, без конкретики.

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

Интерфейс - это некий набор жестких (аппаратура или функции) и мягких (сигналы или протоколы) методов взаимодействия объектов. Например. Есть у нас интерфейс "поток ввода/вывода". У него есть два метода: записать и прочитать. Создать объект состоящий только из этого интерфейса невозможно - непонятно откуда читать и куда писать. Ты чешешь репу и делаешь пройстейшую реализацию - чтение/запись в файл. Для этого ты наследуешься от этого интерфейса и переопределяешь его абстрактные методы и добавляешь свои для открытия и закрытия файла. Через какое-то время у тебя появилась необходимость для ускорения программы в паре сложных мест писать не в файл, а в память. Ты делаешь еще одного наследника от указанного интерфейса... при этом сами функции, использующие поток, тебе менять нет необходимости - интнрфейс общий, отличия только на этапе создания объекта потока.

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

Этот ответ добавлен с нового Винграда - http://vingrad.com

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


Волк и млекопитающее  - это не одно и тоже.
Просто волк - это млекопитающее, причем и то и другое - живое_сущесто. =)))

словарь:
Интерфейс - живое_существо.
API - млекопитающее
COM-интерфейсы - волк.

hoz, 
Попробую и я пояснить тебе, что такое "интерфейс".

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

Когда разработчик "чего-то" хочет рассказать как его разработкой можно взаимодействовать вот тут-то и всплывает понятие "интерфейса".

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

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

Обратимся к программированию. С точки зрения интерфейса, есть два типа программистов:
1) Программисты пользователи
2) Программисты создатели

К примеру, когда вы пишите программу с консольным интерфейсом то придумываете как можно вашей программой пользоваться и здесь вы выступаете в роли программиста создателя. Как только ваша программа попала в руки другого программиста он начинает ей пользоваться, пишет скрипты или вызывает в коде своей программы или еще что-то делает. Этот программист выступает как программист пользователь.

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

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

увы нет, неизменненный интерфейс не явмяется гарантией неизменности логики.. 

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

Но, если человек хороший и позитивный, он или пометит что-либо "depricated"(к примеру std::auto_ptr не удален же!!! Нам программистам дали возможность его выпилить). Либо программист сразу изначально хорошо подумает и сделает хороший интерфейс, к примеру пользуясь Test Driven Development можно получить очень удачные интерфейсы ;)

... я т вроде о неизменном.. 

Ну ок. Мы все юзаем "базовый класс" "мобильный телефон". К пример Вы продали\подарили\потеряли\украли свой старый Nokia 7500 Prism и купили себе новый HTC Desire. Какова Ваша реакция если вместо попытки звонить по нажатию "зеленой клавиши" на экране вы будете видеть выключение устройства?

О неизменности поведения говорит нам принцип "Принцип подстановки Лискоу". Если мы в базовом класс сделали "дозвон", то в потомке должно быть именно дозвоном и ничем другим!

  с поправкой, что это вывод от обратного 

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

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

Так что давайте сойдемся на том, что у моделей бывают интерфейсы. От самых больших до самых крохотных.

Этот ответ добавлен с нового Винграда - http://vingrad.com

А чем как правило является интерфейс при программировании на C++ или Java языках? Пишут как раз таки базовый класс с набором чистых виртуальных функций

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

Это сообщение отредактировал(а) hoz - 1.7.2013, 00:04

Вообще-то, хронологически раньше COM-технологий появилась модель СORBA. COM технологии всего лишь сужение или менее универсальная аналогия Corba-архитектуры. И хронологически СOM переходной ступенькой к платформе .NET.

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

А по сути потребность в ActiveX (COM) объектах была очень большой, да и сейчас они для Windows важны. Несмотря на NET.

PS. Браузеры начинают задыхаться и дико тормозить. В JavaScript появилось дикое количество новых библиотек, которые жутко пожирают память и прочие ресурсы. Так что есть возможность, что Интернет захлебнётся через год-два именно из-за этого.

Этот ответ добавлен с нового Винграда - http://vingrad.com

hoz, Технология COM, как уже заметили выше это своего рода ступенька к другой технологии, технологии .NET. Но и сейчас COM используется, к примеру технология OPC (OLE For Process Control) это теже самые COM-сервера! Они пишутся согласно стандартам OPC-технологии, но чисто технически это COM-сервера. Применяются в SCADA системах. К примеру любое современное производство необходится без SCADA-систем, примеры: ТЭЦ, Нефтепереработка, Химическое производство, даже на Московском монорольсе говорят тоже есть OPC-сервера.

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

Технология COM до сих пор живет и применяется.

Угу, только совсем недавно был заказ на ActiveX компонент для показа анимированных gif-файлов (там были какие-то отличительные черты, которых не было у существующих обнаруженных заказчиком ActiveX-компонентов). Ну, задачи бывают. Правда, такие заказы идут не каждый день.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Кто спорит? Уверен, что кому-то еще и специалисты по dos и mfc нужны. Но это не отменяет устаревание и изначальную неудачность интерфейсов.

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