Поліморфізм — важливий механізм в програмуванні, що дозволяє використовувати спільний інтерфейс для обробки даних різних спеціалізованих типів. Прикладом може слугувати перевантаження методів. З появою ООП концепція поліморфізму розширилась. В контексті об'єктно-орієнтованого програмування, найпоширенішим різновидом поліморфізму є здатність екземплярів підкласу грати роль об'єктів батьківського класу, завдяки чому екземпляри підкласу можна використовувати там, де використовуються екземпляри батьківського класу.
Вступ у поліморфізм об'єктів
Так, уявімо, у нас є клас Солдат та на його основі створено класи Генерал та Сержант. Логічно, що кожен Генерал є солдатом і кожен Сержант є солдатом, проте не кожен солдат є Генералом чи Сержантом. Тож Генерал може виконувати функції звичайного солдата, а солдат функції Генарала не зможе. Все вищесказане в ООП реалізовується через об’єктні змінні, які є поліморфними. Тому в коді ми можемо писати наступні інструкції:
// звичайне створення об'єкту Soldier
Soldier s = new Soldier("Солдат");
// об'єктна змінна типу Soldier посилається на об'єкт типу General
Soldier s2 = new General("Генерал");
Проте якщо б ми зробили б навпаки, спробували із солдати зробити генерала, то наступний рядок викликав би помилку на етапі компіляції:
// !!! Помилка приведення типу (солдат не генерал)
General g=new Soldier("Солдат");Можна спробувати здійснити приведення до типу General, компілятор пропустить, проте під час виконання програми знову ж виникне помилка приведення типу (виняток виду: java.lang.ClassCastException:
osvjava.ua.Soldier cannot be cast to osvjava.ua.General ): General g=(General)new Soldier("Солдат"); // ПОМИЛКА ВИКОНАННЯ!!!Проте коли ми звертаємося до Генерала як до Солдата, то і функціональні можливості Генерала звужуються. Ми можемо викликати методи класу Солдат, проте з методами класу Генерал будуть проблеми. Наприклад, в класі Soldier є метод getHealth(), а в класі General є метод getSlogan():
//змінна sg посилається на об'єкт типу General
Soldier sg= new General("Генерал"); sg.getHealth(); //методи класу Soldier доступні // sg.getSlogan(); //методи класу General недоступніПроте, якщо б метод getSlogan був би у класі Soldier, то викликана б була версія методу getSlogan класу General, оскільки при поліморфізмі заміщення методів все ж відбувається (крім статичних методів).
Якщо нам все ж необхідно звернутися до специфічних методів класу General, які притаманні лише йому, то необхідно створити відповідну об’єктну змінну типу General та здійснити явне приведення типу:
General general=(General)sg; // наш Генерал тепер повноцінний general.getSlogan(); // метод класу General доступний
Якщо виникає необхідність визначити, до якого класу належить відповідний об’єкт, то можна використати метод getClass(), який може викликати будь-який об’єкт оскільки він дістається йому від прабатька усіх класів Object:
System.out.println(sg.getClass()); // результат: class osvjava.ua.GeneralВласне об’єктні змінні класу Object доволі часто застосовується з метою збереження посилань на інші класи. Це дозволяє одночасно працювати з різнотипними об’єктами. Наприклад, можна, тримати різнотипні об’єкти в одному масиві типу Object. Також використання поліморфних об’єктних змінних дозволяє створювати своєрідні універсальні класи та методи (узагальнене програмування). Таким чином непотрібне створення великої кількості перевантаження методів з різним типом параметрів. Власне практично всі внутрішні бібліотеки Java спочатку будувалася таким чином. Щоправда, використання поліморфних змінних може слугувати джерелом багатьох помилок, тому в Java починаючи з JSE 5.0 у мову введено так звані Узагальнення (Generics), які дозволяють більш краще будувати такі універсальні засоби (дивіться детальніше відповідний розділ даного вікіпідручника). Приклади використання поліморфізму
Вище наведено основні правила використання поліморфних об’єктних змінних. Проте, щоб зрозуміти усе вищесказане та користь від поліморфізму розглянемо повноцінний приклад. Тож розробимо певну заготовку для своєрідної гри-стратегії. Наша заготовка гри повинна оперувати трьома об'єктами Soldier, General, Sergeant та проводитиме бій між двома військовими до загибелі одного із них.
Клас Солдат
Спочатку створимо батьківський клас Soldier. Наш солдат як і у всіх іграх матиме певний рівень здоров’я, певний рівень захисту від ударів (броню), отримуватиме удари (поранення) та наноситиме удари іншому солдату.
package osvjava.ua; import java.util.Random; public class Soldier { protected int health; // здоров'я солдата protected boolean alive = false; // стан (живий чи мертвий) protected int defense = 0; // захист від ударів protected static int count = 0; // лічильник створених об’єктів private int id = 0; // кожен солдат матиме порядковий номер (П№) protected String rank; // ранг солдата ("Солдат", "Генерал", "Сержант" тощо) /** Конструктор * @param rank - ранг солдатау */ public Soldier(String rank) { this.rank=rank; id = ++count; // збільшити count на 1 та присвоїти id; health = 100; // встановлюємо рівень здоров'я alive = true; // оживляємо солдата //надаємо солдату рівень захисту випадковим чином (від 0 до 50) Random randomGen = new Random(); defense = randomGen.nextInt(50); System.out.println(rank+" П№" + id + " is greated: health=" + health + ", defense=" + defense); } /** * @return здоров'я солдата */ public int getHealth() { return health; } /** Дозволяє солдату отримувати пошкодження * @param hit - сила удару * Метод приватний оскільки отримання удару можливе лише через метод hit() */ private void receiveHit(int hit) { if (isAlive() == true) { // обчислюємо пошкодження int damage = defense - hit; // якщо удар пробив захист солдат отримує пошкодження if (damage > 0) { health = health - damage; } else { return; // вийти з методу } //якщо солдат загинув, то вивести відповідне повідомлення //в іншому випадку вивести рівень його здоров'я if (health <= 0) { alive = false; System.out.println("[X] "+rank+" П№" + id + " отримав пошкодження " + damage + " і героїчно загинув"); } else { System.out.println(rank+" П№" + id + " отримав пошкодження " + damage + ". Залишилось здоров'я " + health); } } } /** Метод для нанесення удару * @param targetSoldier - кого вдарити * @param hit - сила удару */ public void hit(Soldier targetSoldier, int hit) { targetSoldier.receiveHit(hit); } /** * Перевіряємо стан солдата * @return живий(true), ні (false) */ public boolean isAlive() { return alive; } /** * Повертає порядковий номер солдата * @return id */ public int getId() { return id; } /** * Заміщення методу toString класу Object * @return опис солдата */ @Override public String toString() { return rank+" П№" + id + ": здоров'я=" + health + ", захист=" + defense; } }
Як бачимо в програмі визначено конструктор Soldier(String rank), який проводить початкову ініціалізацію об’єкту, встановлює рівень здоров’я, оживляє, випадковим чином надає захист та присвоює порядковий номер.
Для того, щоб об’єкт когось вдарив у нас є публічний метод hit(Soldier targetSoldier, int hit), при використанні якого потрібно вказати кого вдарити і з якою силою. Даний метод отримавши аргументи викликає метод hit(int hit) того солдата(інший екземпляр класу Soldier), якому наноситься удар вказаної сили. Метод hit() визначає, яке пошкодження нанесено. Якщо сила удару більша рівня захисту, то наноситься пошкодження, яке рівне defense – hit (захист мінус сила удару). Якщо здоров’я солдата стає менше або рівне 0, то солдат вмирає.
Також у нас є додаткові інформаційні методи getHealth, getId та toString, для отримання інформації про стан нашого об’єкту (тобто солдата).
Для підрахунку кількості об’єктів використана статична змінна count, яка спільно використовується усіма екземплярами класу Soldier.
Більшість полів оголошені з модифікатором доступу protected, таким чином до них матимуть доступ лише об’єкти класу Soldier, його підкласи та об’єкти класів даного пакету. Таким чином клас Soldier певним чином інкапсульовано, проте при створенні класу з оголошенням, що він належить до даного пакету принцип інкапсуляції порушується. Ніщо не завадить напряму змінити health чи інше поле. Краще б було оголосити дані поля приватними, проте тоді б код програми ускладнився б, прийшлось би оголошувати більше методів доступу і відповідно розуміння програми ускладнилось би та й створення нащадків також ускладнюється. Ви можете самі пізніше переробити даний клас.
Наступний клас TestBattle створений для тестування бою між солдатами. Він оголошений у іншому пакеті, для правильного використання класу (щоб не було спокуси обійти наш інкапсульований інтерфейс роботи із солдатами). Якщо ви ще не до кінця розібралися, як працювати із пакетами в Java, то ви можете даний файл розмістити в одному ж каталозі з попереднім прикладом і вказати, що вони належать до одного пакету, або й взагалі прибрати написи з вказанням приналежності пакету (інструкції із словом package) у всіх файлах класів.
Для імітації бою у класі TestBattle визначено метод battle (Soldier s1, Soldier s2), в якому солдат 1 та солдат 2 наносять почергово один одному удари із випадковою силою. Бій проводиться до загибелі одного з них, після чого виводить інформація про переможця.
//TestBattle.java package test.ua; import java.util.Random; import osvjava.ua.Soldier; public class TestBattle { Soldier s1=new Soldier("Солдат"); Soldier s2=new Soldier("Солдат"); public TestBattle() { battle (s1, s2); } public void battle(Soldier s1, Soldier s2) { // бій допоки не виживе хтось один, // сила удару встановлюється випадковим чином Random gen = new Random(); while ((s1.isAlive() == true) && (s2.isAlive() == true)) { s1.hit(s2, gen.nextInt(100)); if (s2.isAlive()) { //якщо другий загинув, то мертві не воюють s2.hit(s1, gen.nextInt(100)); } } //виводимо переможця if (!s1.isAlive()) { // idWinner = soldiers[0].getId(); System.out.println("***** Кінець бою. Переміг " + s2 + " *****"); } else System.out.println("***** Кінець бою. Переміг " + s1 + " *****"); } public static void main(String[] args) { // створюємо об’єкт даного класу, виконання продовжиться з конструктора new TestBattle(); } }
Результат:
Солдат П№1 is greated: health=100, defense=10 Солдат П№2 is greated: health=100, defense=27 Солдат П№1 отримав пошкодження 9. Залишилось здоров'я 91 Солдат П№2 отримав пошкодження 18. Залишилось здоров'я 82 Солдат П№2 отримав пошкодження 19. Залишилось здоров'я 63 Солдат П№1 отримав пошкодження 2. Залишилось здоров'я 89 Солдат П№2 отримав пошкодження 17. Залишилось здоров'я 46 Солдат П№1 отримав пошкодження 6. Залишилось здоров'я 83 Солдат П№2 отримав пошкодження 4. Залишилось здоров'я 42 Солдат П№2 отримав пошкодження 11. Залишилось здоров'я 31 Солдат П№1 отримав пошкодження 1. Залишилось здоров'я 82 Солдат П№2 отримав пошкодження 4. Залишилось здоров'я 27 Солдат П№2 отримав пошкодження 23. Залишилось здоров'я 4 Солдат П№1 отримав пошкодження 8. Залишилось здоров'я 74 [X] Солдат П№2 отримав пошкодження 5 і героїчно загинув ***** Кінець бою. Переміг Солдат П№1: здоров'я=74, захист=10 *****
Сержанти та Генерали
Тепер же ускладнимо гру. У нас з’являються нові персонажі Генерали та Сержанти. Відмінність у них від звичайних солдат у кількості здоров’я, плюс генерали матимуть свій лозунг та метод його одержання.
// Sergeant.java package osvjava.ua; public class Sergeant extends Soldier { public Sergeant(String rank){ // спочатку створюється солдат, на основі якого створюється наш сержант super(rank); // збільшуємо здоров'я сержанта у 10 раз super.health=super.health*10; System.out.println("Здоров'я сержанта збільшено в 10 раз"); } }
Як бачимо клас сержанта доволі простий. При оголошенні класу ми написали, що він розширює клас Soldier. Далі визначили конструктор даного методу, який в свою чергу викликає конструктор суперкласу передаючи йому ранг. Якщо б ми б не визначили б конструктори у даних класах, а існували б лише конструктори по замовчуванню. То виклик конструкторів по замовчуванню відбувався б у тій же послідовності. При виклику конструктора Sergeant із нього б викликався конструктор Soldier і лише після створення Солдата відбувалось би створення Сержанта. Такий же механізм реалізовано в даному прикладі явно.
При створенні сержанта інструкцією new Sergeant(“Sergeant”), ми отримуємо наступне:
Сержант П№1 is greated: health=100, defense=45 Здоров'я сержанта збільшено в 10 раз
Тепер же опишемо нашого Генерала із кількома власними методами і своїм лозунгом.
//General.java package osvjava.ua; public class General extends Soldier { private String slogan = "Ніколи не здаватись"; // Лозунг генерала /** Конструктор * @param rank - ранг солдата ("Генерал") */ public General(String rank) { // спочатку створюється солдат, на основі якого створюється наш генерал super(rank); // збільшуємо здоров'я генерала у 100 раз super.health = super.health * 100; System.out.println("Здоров'я генерала збільшено у 100 раз"); } /** Тепер заміщується метод toString класу Soldier * @return Стан генерала із лозунгом */ @Override public String toString() { return "Генерал із здоров'ям " + super.health + " його лозунг: " + slogan; } /**Отримати лозунг генерала * @return лозунг */ public String getSlogan() { return slogan; } }
Давайте заставимо нашого генерала битися із сержантом. Оскільки вони розширяють клас Soldier, то нам непотрібно створювати новий метод battle() з параметрами типу General та Sergeant. Створений попередньо метод цілком підходить
Sergeant ser=new Sergeant ("Сержант"); General gen=new General ("Генерал"); battle (ser, gen):
Результат виконання:
Сержант П№1 is greated: health=100, defense=12 Здоров'я сержанта збільшено в 10 раз Генерал П№2 is greated: health=100, defense=29 Здоров'я генерала збільшено у 100 раз Сержант П№1 отримав пошкодження 1. Залишилось здоров'я 999 Генерал П№2 отримав пошкодження 4. Залишилось здоров'я 9996 ... Сержант П№1 отримав пошкодження 12. Залишилось здоров'я 4 Генерал П№2 отримав пошкодження 20. Залишилось здоров'я 5173 Генерал П№2 отримав пошкодження 6. Залишилось здоров'я 5167 [X] Сержант П№1 отримав пошкодження 8 і героїчно загинув ***** Кінець бою. Переміг Генерал із здоров'ям 5167 його лозунг: Ніколи не здаватись *****
Як і можна було сподіватись, сили були занадто нерівні:). Генерал переміг
Таким чином завдяки тому, що наш метод battle використовує об’єктні змінні типу Soldier він без проблем приймає змінні типу Sergiant та General. Звичайно, що при цьому дані дочірні класи повинні битися через інтерфейс описаний у батьківському класі. Якщо вони реалізовуватимуть бій власним чином, то метод battle можливо не працюватиме правильно.
Крім того згадаймо метод hit(Soldier targetSoldier, int hit) класу Soldier. Там використовується посилання на об’єкт класу Soldier проте після успадкування даного методу він продовжує правильно працювати і з об’єктами Sergeant та General. Це також можливо завдяки поліморфізму.
Створюємо Армію
Також ми можемо зібрати усіх переможців в одну армію і підрахувати загальне здоров’я даної армії.
Ось клас Army, доволі простий, лише додає солдат до армії і в ньому існує метод, який підраховує здоров’я армії:
package osvjava.ua; public class Army { protected int num=99; protected Soldier[] soldiers; static int count=0; public Army() { soldiers=new Soldier[num]; } /** Метод зарахування солдата в армію * @param soldier * @return true - солдата додано, false - помилка */ public boolean addSoldier(Soldier soldier) { if (count>=num) return false; this.soldiers[count]=soldier; count++; return true; } /** Підрахунок здоров'я армії * @return Сумарне здоров'я усіх солдат в армії */ public int calcArmyHealth() { int armyHealth=0; for (int i = 0; i < count; i++) { armyHealth+=soldiers[i].getHealth(); } return armyHealth; } }
А ось клас для тестування:
package test.ua; import java.util.Random; import osvjava.ua.Army; import osvjava.ua.General; import osvjava.ua.Sergeant; import osvjava.ua.Soldier; public class TestBattle2 { Sergeant ser=new Sergeant ("Сержант"); General gen=new General ("Генерал"); Soldier[] s= new Soldier[100]; Army army=new Army(); public TestBattle2() { s[0] = new Soldier("Солдат"); s[1] = new Soldier("Солдат"); s[2] = new Soldier("Солдат"); s[3] = new Soldier("Солдат"); army.addSoldier(battle (ser, gen)); army.addSoldier(battle (s[0], s[1])); army.addSoldier(battle (s[2], s[3])); System.out.println("Сумарне здоров'я армії "+ army.calcArmyHealth()); } public Soldier battle(Soldier s1, Soldier s2) { // бій допоки не вижеве хтось один, // сила удару встановлюється випадковим чином Random gen = new Random(); while ((s1.isAlive() == true) && (s2.isAlive() == true)) { s1.hit(s2, gen.nextInt(100)); if (s2.isAlive()) { //якщо другий загинув, то мертві не воюють s2.hit(s1, gen.nextInt(100)); } } //виводимо переможця if (!s1.isAlive()) { // idWinner = soldiers[0].getId(); System.out.println("***** Кінець бою. Переміг " + s2 + " *****"); return s2; } else{ System.out.println("***** Кінець бою. Переміг " + s1 + " *****"); return s1; } } public static void main(String[] args) { new TestBattle2(); } }
Як бачимо у класі Army для того, щоб просумувати здоров’я усіх солдат, нам не знадобилося три масиви типу Soldier, Sergeant та General, замість цього ми використали один масив Soldier, у який поміщаємо як рядових солдат так і генералів та сержантів. Метод army.calcArmyHealth() підбиває усе здоров’я армії простим перебором елементів масиву. Зверніть увагу як модифіковано метод battle у класі TestBattle2, тепер він повертає посилання на переможця: тип повернення Soldier.
Як вже зазначалося у вступі до поліморфізму, якщо ми хочемо викликати методи дочірніх класів, то прийдеться здійснити явне приведення до типу дочірнього класу, інакше методи General будуть недоступні ззовні, хоча всередині себе об’єкт без проблем застосовує власні методи та поля. Також, якщо в дочірньому класі перевизначено метод батьківського класу(в даному випадку метод toString), то навіть при використанні об’єктного посилання батьківського класу, метод усе рівно буде заміщено (override) (крім статичних методів). Нестатичні методи можна перевизначити у дочірньому класі, проте при поліморфізмі вони не будуть заміщатися. При виклику статичного метода об'єкту типу General, через об’єктну змінну типу Soldier буде викликаний метод Soldier, а не визначений в General одноіменний статичний метод. Все це потрібно враховувати при створенні власних програм. Тому виділіть час і поекспериментуйте з механізмами успадкування і поліморфізму, хоча б на даних прикладах.
Структура створених вищенаведених класів зображено на UML діаграмі. UML діаграма класів
Власне, щоб не повторювати постійно метод battle при тестуванні, його б було доцільно розмістити у відповідному класі Battle. Можете зробити це самостійно. Також було б непогано реалізувати бій між арміями, а не тільки між двома солдатами.
Дякую за статтю. Одна найкращих статей на українській чи російській мові в інтернеті. Дуже чітко пояснено усі моменти, а не як зазвичай, коли увесь поліморфізм пояснюють лише на одному наслідуванні.
ВідповістиВидалити