Лекція 4:

Тема: Поняття об’єкту. Наслідування. Інкапсуляція. Поліморфізм. Віртуальні та абстрактні методи. Динамічне створення об’єктів

План:

2. Об'єктно-орієнтовані мови програмування.

3. Етапи розробки програмних систем з використанням ООП.

3. Властивості ООП.

1. Об'єктно-орієнтовані мови програмування

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

Примітка. Окрім цього, в теорії програмування прийнято розрізняти об'єктно-орієнтовані і об'єктні мови програмування. Останні відрізняються тим, що вони не підтримують спадкоємства властивостей в ієрархії абстракцій, наприклад, Пекла - об'єктна мова, а C++ і об'єктні версії Паскаля - об'єктно-орієнтовані.

Не дивлячись на те, що принципово ООП можливо на багатьох мовах програмування, бажано для створення об'єктно-орієнтованих програм використовувати об'єктно-орієнтовані мови, що включають спеціальні засоби, наприклад, Borland Pascal (починаючи з версії 5.5), C++, Delphi і так далі

У таблиці представлені порівняльні характеристики мовних засобів, що розглядаються в наступних розділах.

Найпростіша об'єктна модель використана при розробці Borland Pascal 7.0. Вона спеціально створювалася для полегшення переходу програмістів на використання технології ООП і не підтримує абстракції метаклассов, майже не містить спеціальних засобів заховання реалізації об'єктів. Але навіть в такому варіанті вона дозволяє створювати достатньо складні системи. Об'єктні моделі решти мов є практично повними.

Особливе місце займають об'єктні моделі Delphi і C++Builder. Ці моделі узагальнюють досвід ООП для MS DOS і включають деякі нові засоби, що забезпечують ефективне створення складніших систем. На базі цих моделей створені візуальні середовища для розробки застосувань Windows. Складність програмування під Windows вдалося істотно понизити за рахунок створення спеціальних бібліотек об'єктів, що «заховали» багато елементів техніки програмування.

2. Етапи розробки програмних систем з використанням ооп

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

Розглянемо ці етапи.

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

Проектування. Розрізняють:

1. логічне проектування, при якому ухвалювані рішення практично не залежать від умов експлуатації (операційної системи і використовуваного устаткування);

2. фізичне проектування, при якому доводиться приймати до уваги вказані чинники.

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

Фізичне проектування включає об'єднання описів класів в модулі, вибір схеми їх підключення (статична або динамічна компоновка), визначення способів взаємодії з устаткуванням, з операційною системою і/або іншим програмним забезпеченням (наприклад, базами даних, мережевими програмами), забезпечення синхронізації процесів для систем паралельної обробки і так далі

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

Використання поетапної реалізації істотно спрощує тестування і відладку програмного продукту.

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

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

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

Розгляд основних прийомів об'єктного підходу почнемо з об'єктної декомпозиції.

Об'єктна декомпозиція

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

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

Функціональні елементи системи, параметри і поведінка якої визначаються умовою завдання, що володіють самостійною поведінкою (тобто що «уміють» виконувати деякі дії, залежні від отриманих повідомлень і стану елементу), отримали назву об'єктів.

Процес представлення наочної області завдання у вигляді сукупності об'єктів, що обмінюються повідомленнями, називається об'єктною декомпозицією.

Дня того щоб зрозуміти, про які об'єкти і повідомлення йде мова при виконанні об'єктної декомпозиції у кожному конкретному випадку, слід пригадати, що спочатку об'єктний підхід був запропонований для розробки імітаційних моделей поведінки складних систем. Набір об'єктів таких систем зазвичай визначається при аналізі модельованих процесів.

Проілюструємо спочатку на дуже простому прикладі ідею об'єктної декомпозиції для завдань, не пов'язаних з імітацією.

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

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

	Намалювати		Намалювати
	Змінити колір		Змінити колір
	Змінити розмір		Змінити розмір
	Змінити координати		Змінити координати

Мал. 4. Діаграма об'єктів графічного редактора

Основний процес системи - процес управління малюванням фігур, вказаних користувачем. Всі команди користувача повинні інтерпретуватися, і в результаті інтерпретації повинні формуватися команди на малювання або зміну параметрів фігур. Ці процеси можна моделювати, використовуючи три об'єкти: Монітор (блок управління, який отримує і інтерпретує команди користувача) і два об'єкти - фігури (мал. 4), кожен зі своїми параметрами.

Фігури отримують наступні повідомлення: «Намалювати», «Змінити колір контура», «Змінити розмір», «Змінити координати». Всі ці повідомлення ініціюються Монітором відповідно до команди користувача. Отримавши від користувача команду «Завершити», Монітор припиняє виконання програми.

Приклад Об'єктна декомпозиція (програма «Записник»). Спробуємо виконати об'єктну декомпозицію для програми «Записник», на якій раніше демонструвалася специфіка процедурної декомпозиції.

Як вже констатувалося раніше, роботу з програмами такого типу користувачеві зручніше здійснювати через меню. Значить, при запуску програми на екрані повинне з'явитися меню, що містить набір можливих операцій. Залежно від вибору користувача далі активізуватимуться частини програми, відповідальні за відкриття «книжки», додавання записів або за пошук записів (мал. 5).

На цьому етапі аналізу ми вже можемо виділити чотири самостійні частини програми, які взаємодіють в процесі її виконання: Меню, Відкриття книжки, Введення записів, Пошук записів. Частина Меню є такою, що управляє і активізує в процесі роботи з програмою решту частин для виконання необхідних операцій.

Початок роботи

Кінець роботи

Мал. 5. Діаграма станів інтерфейсу користувача (перший варіант)

Додамо до системи ще декілька видимих об'єктів - повідомлень користувачеві, які з'являтимуться на екрані при виявленні невідповідностей в процесі роботи, наприклад, «записник не знайдений» активізується Відкриттям книжки чи ні інформації про абонента» - активізується Пошуком записів (мал. 6). Об'єкти Меню, Відкриття книжки, Введення записів, Пошук записів в процесі роботи повинні отримувати інформацію від користувача і повідомляти йому результати роботи, і відповідно повинні мати деяке екранне уявлення. Сукупність таких екранних уявлень (форм) утворює інтерфейс з користувачем.

Крім об'єктів інтерфейсу система містить ще, принаймні, один об'єкт - Файл записів, використовуваний для зберігання введеної інформації. Цей об'єкт повинен отримувати від Відкриття, Введення і Пошуку повідомлення-команди відповідно відкриття файлу, додавання інформації і пошуку. Команда відкриття повинна супроводжуватися ім'ям файлу, команда додавання інформації - ідентифікаційним заголовком і телефоном, а команда пошуку - ідентифікаційним заголовком.

Начало работы

Завершение работы

Мал. 6. Повна діаграма станів інтерфейсу користувача

Об'єкт Меню відповідатиме за вибір пунктів меню і виклик форми Відкриття, форми Введення і форми Пошуку.

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

Форма Введення повинна вводити дані (прізвище, ім'я, по батькові і телефон) і передавати цю інформацію об'єкту Файл для збереження.

Форма Пошук повинна вводити дані для пошуку (прізвище або ім'я, або і те і інше відразу) і запрошувати пошук телефону за введеними даними.

Всі операції з файлом виконуватиме об'єкт Файл.

Остаточний варіант об'єктної декомпозиції проектованої системи представлений на мал. 7 (порівняєте з результатами процедурної декомпозиції для тієї ж програми, приведеними на мал. 6).

Таким чином, можна сформулювати наступні рекомендації по виконанню об'єктної декомпозиції:

1. Для складних систем об'єктна декомпозиція повинна виконуватися поетапно: на першому етапі - об'єктна декомпозиція всієї системи, на подальших - декомпозиція об'єктів як підсистем.

2. При декомпозиції системи в цілому як об'єкти можуть виділятися елементи двох типів:

• елементи інтерфейсу користувача (вікна меню, вікна повідомлень, вікна форм введення-виводу і так далі);

• засоби зберігання, організації і перетворення даних (бази даних, файли, протоколи, структури даних і так далі).

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

3. Процес декомпозиції припиняється при отриманні об'єктів, які можуть бути досить просто реалізовані, тобто мають чітко певну структуру і поведінку.

Об'єкти і повідомлення

Раніше було сказано, що під об'єктом стосовно ООП розуміється частина наочної області завдання, що окремо реалізовується. Програма, що розробляється, таким чином, складається з об'єктів, які взаємодіють через передачу повідомлень.

Кожен об'єкт, отримуючи повідомлення, повинен певним чином «реагувати» на них, виконуючи заздалегідь визначені для кожного типу повідомлення дії. Наприклад, якщо об'єкт Форма Відкриття з прикладу буде активізовано, то він повинен запитати у користувача ім'я файлу, перевірити наявність такого файлу і потім або відкрити його, пославши відповідне повідомлення об'єкту Файл, або активізувати об'єкт Повідомлення «записник не знайдений».

Реакція об'єкту на повідомлення може залежати від його стану: так об'єкт Файл, отримавши повідомлення «Додати запис», перш ніж додавати запис, повинен перевірити, чи відкритий відповідний файл, і при закритому файлі повинен видати користувачеві відмову на виконання операції додавання.

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

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

Примітка. Наявність внутрішнього стану об'єктів означає, що порядок виконання операцій має істотне значення.

Поведінка об'єктів, як вже мовилося вище, характеризується певним набором реакцій на отримувані повідомлення і часто залежить від стану об'єкту.

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

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

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

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

Повний список можливих операцій над об'єктами виглядає таким чином:

• створення об'єкту;

• знищення об'єкту;

• модифікація - зміна стану об'єкту; селекція - доступ для визначення стану;

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

Відповідно, кожне повідомлення, що приймається об'єктом, можетинициировать виконання однієї або декількох операцій вказаних типів.

При виконанні об'єктної декомпозиції встановлюються відносини між об'єктами, які бувають двох типів.

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

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

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

Види операцій над об'єктами і типи відношення між ними визначають особливості реалізації об'єктів.

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

Класи. Для представлення абстракцій об'єктів використовується спеціальний визначуваний програмістом тип даних - клас.

Клас - це структурний тип даних, який включає опис полів даних, а також процедур і функцій, що працюють з цими полями даних. Стосовно класів такі процедури і функції отримали назву методів.

Об'єкт-змінна

Значення

методи

Об'єкт – абстракция Клас

Стан

Поведінка

Поля

Методи

Об'єкт-змінна

Значення

методи

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

У програмах використовуються змінні типу класу. Такі змінні прийнято називати об'єктами.

Приклад 1 Опис класу (клас Вікно). Хай необхідно розробити клас, змінні якого використовуються для зображення на екрані кольорового прямокутника заданого кольору і розміру (мал. 2). Проектований клас повинен містити поля для збереження параметрів вікна: XI, Yl, X2, Y2 - координати верхнього лівого і нижнього правого кутів і Color - колір.

Х

Цвет

A(x1,y1)

B(x2,y2)

Рис. 2 Вид и параметры окна на экране

Колір

A(x1,y1)

B(x2,y2)

Рис. 2 Вид и параметры окна на экране

ай єдине повідомлення, що обробляється об'єктом, - «Намалювати вікно». Відповідно, клас повинен містити метод, що реалізовує процес малювання об'єкту. Поля об'єкту можна ініціалізувати при створенні Змінній - y(х2 у2) об'єкту, передавши йому повідомлення ініціалізації, що включає значення полів.

Отже, клас повинен містити метод ініціалізації.

Остаточно отримуємо клас, що має наступну структуру:

Клас Вікно:

поля X1,Y1,X2,Y2, Color

метод Ініціалізувати(аХ 1,aY I,aX2,aY2,aColor)

метод Зобразити

Кінець опису.

Створюючи об'єкти типу Вікно, ініціалізувавши їх відповідно до умови і посилаючи їм повідомлення «Намалювати вікно», отримаємо різні вікна на екрані, причому параметри цих вікон зберігатимуться в об'єктах.

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

Дія на об'єкт виконується за допомогою зміни його полів або виклику його методів. Доступ до полів і методів об'єкту здійснюється, за винятком спеціальних випадків, з вказівкою імені об'єкту (при цьому використовуються складені імена):

<ім'я об'єкту>.< ім'я поля>

або

<ім'я об'єкту>.< ім'я методу>.

Всі методи об'єкту обов'язково мають доступ до всіх полів свого об'єкту. У мовах програмування, що розглядаються далі, це досягається через неявну передачу в метод спеціального параметра - адреси області даних конкретного об'єкту (Self- в Паскалі і this - в C++). Таким чином, зменшується кількість параметрів, явно передаваних в метод.

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

Клас <ім'я класу>

інтерфейс

<оголошення полів і методів класу, до яких можливе звернення ззовні>

реалізація

<оголошення полів і методів класу, до яких неможливе звернення ззовні>

Кінець опису.

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

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

Інтерфейс

Методи

Реалізація

Методи

Мал. 3 Інтерфейс і реалізація класу

З іншого боку доступ до об'єкту регламентується і повинен виконуватися через спеціальний інтерфейс (мал. 3).

Як і будь-яка змінна програми, об'єкт повинен бути розміщений в пам'яті (створений) і видалений з пам'яті (знищений). Причому створення і знищення об'єктів виконується статично або динамічно.

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

Динамічне створення і знищення об'єктів виконується в процесі роботи програми спеціальними командами.

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

Приклад 2. Заховання реалізації класу (клас Файл - продовження прикладу). Відповідно до результатів об'єктної декомпозиції. Файл повинен реагувати на наступні повідомлення: «Відкрити», «Додати запис», «Знайти запис».

Кожне повідомлення повинне доповнюватися необхідною інформацією. Так, повідомлення «Відкрити» повинно супроводжуватися передачею імені файлу. Повідомлення «Додати запис» повинно супроводжуватися передачею тексту запису, що складається з двох частин: прізвища абонента або назви організації і телефону. Повідомлення «Знайти запис» повинно супроводжуватися передачею прізвищу абонента або назви організації, по яких повинен бути знайдений телефон. Кожному повідомленню повинен відповідати метод, що оголошений в інтерфейсній частині класу і реалізовує необхідні дії.

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

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

Метод Знайти також спочатку повинен перевіряти, чи відкритий файл. Якщо файл відкритий, метод вьполняет пошук інформації у файлі. Операції перевірки відкриття файлу виконуються в методах Додати і Знайти ідентично, їх можна виділити в окремий метод Проверкаоткритія, який можна описати в секції реалізації.

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

Остаточно для реалізації об'єкту Файл можна запропонувати клас наступної структури:

Клас Файл:

інтерфейс

конструктор Ініціалізувати;

метод Відкрити (ім'я файлу);

метод Додати (прізвище, телефон);

метод Знайти (прізвище);

деструкція Закрить_файл;

реалізація

поле Файловая_переменная;

поле Состояніє_файла;

метод Проверка_откритія;

Кінець опису.

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

У програмі повинна бути використана змінна типу Файл. Оскільки файл в програмі використовується постійно, відповідну змінну краще визначати статично.

Передача повідомлень об'єкту буде реалізована як виклик відповідного методу інтерфейсної частини.