14. Інтерфе́йс -сукупність засобів і правил, що забезпечують взаємодію пристроїв обчислювальної системи та (або) програм;

сукупність описів і узгоджень про процедуру передачі управління в підпрограму та повернення в вихідну програму.

Інтерфейс (від англ. Interface — поверхня розділу, перегородка) — сукупність засобів, методів і правил взаємодії (управління, контролю і т. д.) між елементами системи. Цей термін використовується в багатьох галузях науки і техніки. Його значення відноситься до будь-якого сполучення взаємодіючих сутностей (як природничих, так апаратних і людино-машинних). Під інтерфейсом розуміють не тільки пристрої, але й правила (протокол) взаємодії цих пристроїв.

Приклади:

віжки — головний елемент інтерфейсу між конем і кучером, або ж, — інтерфейс системи «кінь-кучер»);

кермо, педалі газу і гальма, ручка КПП — інтерфейс (управління) автомобіля або ж інтерфейс системи «водій-автомобіль»;

електричні вилка і розетка — є інтерфейсом енергопостачання більшості побутових приладів;

елементи електронного апарату (радіо, годинника і т. д.) — дисплей, набір кнопок і перемикачів для настройки, плюс правила керування ними — інтерфейс системи «людина-машина»;

клавіатура і миша — елементи інтерфейсу в системі «користувач-ЕОМ» (у свою чергу, і самі клавіатура і миша мають власні інтерфейси сполучення з комп'ютером);

Залежно від контексту, поняття застосовне як до окремого елементу (інтерфейс елементу), так і до зв'язка елементів (інтерфейс сполучення елементів).

У контексті окремого елемента інтерфейс елемента протилежний реалізації елементу (внутрішньому устрою та функціонування). Користувачеві елемента немає потреби знати, як реалізований використовуваний елемент, щоб керувати ним, але використовуваний елемент має надати інтерфейс управління. Наприклад, водієві зовсім не обов'язково знати, як влаштований двигун, щоб керувати автомобілем, достатньо користуватися інтерфейсом автомобіля (кермом і педалями).

15. За аналогією з параметризованих функцією можна побудувати параметризрвані опис класу, що дозволяє створювати екземпляри класів для конкретних значень параметрів. Параметризованих клас описується наступним чином:

template <class T>

class опис класу

Як і для функцій, в описувач template може бути як завгодно багато параметрів. У самому опис класу імена параметрів використовуються як імена типів даних, типів параметрів функцій і типів значень, що повертаються функціями. В якості прикладу наведемо опис класу stack, призначеного для побудови стеків фіксованого максимального розміру з елементами проізволного типу.

16. Класом будемо називати загальну сутність, яка може бути визначена як сукупність елементів (потрібно зауважити, що клас при об'єктно-орієнтованому підході до програмування - це, як правило, первинне, невизначене поняття, до деякої міри аналогічне теоретико-математичному поняттю множини, або, точніше, домену). Під властивістю (або атрибутом) будемо розуміти пропозиційну функцію, визначену на довільному типі (даних).Методом (або функцією) назвемо операцію, яка визначена над об'єктами того чи іншого класу.

Зауважимо, що клас при об'єктно-орієнтованому підході є аналогом поняття типу в тому сенсі, що до нього відносять лише об'єкти, відібрані за певним правилом. Це правило можна формулювати математично за допомогою предикатной функції, тобто функції, область значень якої збігається зі значеннями істинності: "істина" і "брехня". При цьому той чи інший об'єкт належить до класу, якщо значення аплікації функції до даного об'єкту слово, не відноситься в іншому випадку.

Функцію такого роду прийнято називати індивідуалізуючою функцією. Індивідуалізуюча функція фактично є моделлю експертної класифікації.

Важливою умовою при дослідженні об'єктно-орієнтованого підходу до програмування є встановлення взаємозв'язків фундаментальних сутностей. Зазначимо у цьому зв'язку, що поняття класу є спочатку більш загальним, ніж поняття об'єкта. Точніше, кажуть, що об'єкт є екземпляром (instantiation) класу.

Таким чином, клас може розглядатися як сукупність об'єктів (подібно до того як множина або домен є сукупністю елементів).

У рамках об'єктно-орієнтованого підходу до програмування довільний клас може бути елементарним або розділятися на підкласи (подібно до того як множина або домен підрозділяється на підмножини або субдомени).

Наприклад, більш загальний клас PERSON може містити усередині себе підклас STUDENT, який, у свою чергу, містить конкретний об'єкт John_Smith. Як зазначалося у вступній лекції, в 90-і роки В.Е. Вольфенгагеном (Vyatcheslav E. Wolfengagen) була створена так звана дворівнева схема концептуалізації, заснована на дворазовому застосуванні постулату згортання, до певної міри аналогічного операції ламбда-абстракції. Розглянемо більш детально основні аспекти даної формалізації об'єктно-орієнтованого підходу до програмування. У загальних рисах схема побудови моделі виглядає наступним чином.

Основу моделі складає типізований варіант ламбда-числення, семантика якого моделюється за допомогою повних і безперервних решіток Д. Скотта. Для опису об'єктів довільної складності вводяться аплікативні структури з приписуванням типів. Остання обставина необхідна для формалізації ієрархії класів, в які об'єднуються об'єкти.

17.Модель компонентних об’єктів ( COM ) Microsoft спирається на використання інтерфейсів. Перевагою використання побудованого на інтерфейсах програмного коду є можливість розробки різних компонент-орієнтованих систем, включаючи розподілені компонент-орієнтовані системи.

Щоб краще зрозуміти суть моделі COM, необхідно розглянути причини, які призвели до її розробки. Модель COM досить довго перебувала на задньому плані тільки через те, що корпорація Microsoft не потурбувалась над тим, щоб пояснити спільноті розробників, що це таке і для чого створено. Більшість розробників помилково прийняли її за обновлену версію OLE, старої технології, основаної на динамічному обміні даними, і створеної для зв’язку і впровадження об’єктів при інтеграції продуктів MS Office. Фактично, модель COM була представлена як OLE2, що мало на увазі лише нову версію старих проблем OLE. Таким чином, пройшло немало часу, перш ніж всі зрозуміли, що модель COM володіє значно більшими можливостями, ніж це розуміється в парадигмі «інтерфейс-орієнтовна розробка компонентних систем». Модель COM дозволяє успішно розв’язувати наступні проблеми:

• Багаторазове використання програмного коду. Порівнюючи із звичайною об’єктно-орієнтованою моделлю, модель COM володіє додатковими перевагами, оскільки дозволяє використовувати не тільки файли вихідного коду, але і бінарні файли відкомпільованого коду.

• Незалежність від мови програмування. Об’єкт сервера COM можна написати на одній мові, а об’єкт клієнта, що використовує його, на іншій. Якщо компілятор мови вихідного коду(або відповідна бібліотека часу виконання) має можливість забезпечити створення об’єктного коду, що відповідає стандарту бінарних файлів COM, то ця мова цілком придатна для розробки компонентів COM.

• Незалежність від компілятора і постачальника. Мається на увазі проблема використання бібліотек DLL, що випускаються різними постачальниками програмного забезпечення, які використовують різні компілятори і різний формат імен. Модель COM абсолютно не чутлива до цієї проблеми. Незалежність від мови, в свою чергу, забезпечує також повну незалежність від компілятора, що використовується кожним конкретним постачальником програмного забезпечення.

• Незалежність від розміщення. Клієнт не зобов’язаний знати, де саме розміщений компонент, що являє собою сервер. Його може містити внутрішній процес бібліотеки DLL, локальний сервер EXE, віддалена бібліотека DLL або віддалений сервер EXE.

• Можливість маштабування. Модель COM допускає установку (розгортку) різноманітних компонентів, що дозволяє сконструювати розподілену систему з конфігурацією, що є найбільш ефективною для кожного конкретного випадку, і нарощувати її можливості, додаючи компонент за компонентом(при необхідності навіть динамічно).

• Контроль версій. Що трапиться при спробі встановити стару версію бібліотеки DLL зверху більш нової? В моделі COM – це не проблема, як і багато іншого.

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