28. Поняття інтерфейсів.

Концепція абстрактних методів дозволяє запропонувати альтернативу множинного спадкоємства . У Java клас може мати тільки одного батька , оскільки при множині спадкування можуть виникати конфлікти , які серйозно заплутують об'єктну модель. Наприклад , якщо у класу є два батьки , які мають однаковий метод з різною реалізацією , то який з них успадкує новий клас ? І як працюватиме функціональність батьківського класу , який позбувся свого методу ? Всі ці проблеми не виникають у разі , якщо успадковуються тільки абстрактні методи від декількох батьків. Навіть якщо буде успадковано кілька однакових методів , все одно у них немає реалізації , і можна один раз описати тіло методу , яке буде використано при виклику будь-якого з цих методів . Саме так влаштовані інтерфейси в Java. Від них не можна породжувати об'єкти , але інші класи можуть реалізовувати їх.

Оголошення інтерфейсів дуже схоже на спрощене оголошення класів .

Оголошення починається з заголовка. Спочатку вказуються модифікатори . Інтерфейс може бути оголошений як public , і тоді він буде доступний для загального використання, або модифікатор доступу може не вказуватися , в цьому випадку інтерфейс доступний тільки для типів свого пакета. Модифікатор abstract для інтерфейсу не потрібно, оскільки всі інтерфейси є абстрактними , його можна вказати , але рекомендується цього не робити, щоб не захаращувати код . Далі записується ключове слово interface та ім'я інтерфейсу . Після цього може слідувати ключове слово extends і список інтерфейсів , від яких буде успадковуватися і оголошений інтерфейс. Батьківських типів може бути багато , головне , щоб не було повторень, і щоб ставлення спадкування не утворювало циклічної залежності.

public interface Drawble extends Colorable, Resizable {

}

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

public interface Directions {

int RIGTH=1;

int LETFT=2;

int UP=3;

int DOWN=4;

}

29. Поліморфізм.

Поліморфізм – це правило, що дозволяє визначити, чи варто конкретної ситуації застосовувати успадкування чи ні. Якщо між об'єктами існує відношення «є» («is - a»), то кожен об'єкт підкласу є об'єктом суперкласу. Наприклад, кожен менеджер є співробітником. Отже, має сенс зробити клас Manager подклассом класу Employee. Природно, зворотне твердження невірно - не кожен співробітник є менеджером.

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

Employee e;

e = new Employee(...);  // Объект класса Employee

e = new Manager(...); //  Можно и так

У мові Java об'єктні змінні є поліморфними. Змінна типу Employee може посилатися як на об'єкт Employee, так і на об'єкт будь-якого підкласу класу Employee (наприклад, Manager, Executive, Secretary тощо).

Manager boss = new Manager(...);

Employee[] staff = new Employee[3];

staff[0] = boss;

Тут змінні staff [0] і boss посилаються на один і той же об'єкт. Однак змінна staff [0] розглядається компілятором тільки як об'єкт Employee. Це означає, що допускається наступний виклик:

boss.setBonus(5000); //  Ок

Справа в тому, що змінна staff [0] оголошена як об'єкт Employee, а методу setBonus () у цьому класі немає. Однак привласнити посилання на об'єкт суперкласу змінної підкласу неможливо. Наприклад, наступний оператор є неприпустимим:

Manager m = staff[i]; //  Ошибка

Причина очевидна: не всі співробітники є менеджерами. Якби це привласнення виявилося виконаним, і змінна м могла б посилатися на об'єкт Employee, який менеджером не є, то згодом виявився б можливим виклик методу m.setBonus (...), що призвело б до помилки при виконанні програми.