Іноді має сенс описати тільки заголовок методу, без його тіла, і таким чином оголосити, що даний метод буде існувати в цьому класі. Реалізацію цього методу, тобто його тіло, можна описати пізніше.
Розглянемо приклад. Припустимо, необхідно створити набір графічних елементів, неважливо, яких саме. Наприклад, вони можуть представляти собою геометричні фігури – коло, квадрат, зірка і т.д.; або елементи, призначені для користувальницького інтерфейсу – кнопки, поля введення і т.д. Зараз це не має вирішального значення. Крім того, існує спеціальний контейнер, який займається їх промальовкою. Зрозуміло, що зовнішній вигляд кожної компоненти унікальний, а значить, відповідний метод (назвемо його paint()) буде реалізований в різних елементах по-різному.
Алі в тойже часу компонентів може бути багато спільного. Наприклад, будь-який з них займає деяку прямокутну область контейнера. Складні контури фігури необхідно вписати в прямокутник, щоб можна було аналізувати перекриття, перевіряти, чи не вилазить компонент за межі контейнера, і т.д. Кожна фігура може мати колір, яким її треба малювати, може бути видимою, або невидимою й т.д. Очевидно, що корисно створити батьківський клас для всіх компонентів і один раз оголосити в ньому всі загальні властивості, щоб кожен компонент лише наслідував їх.
Алі як вчинити з методом відтворення? Адже батьківський клас не представляє собою будь-яку фігуру, у нього немає візуального представлення. Можна оголосити метод paint() у кожному компоненті незалежно. Алі тоді контейнер повинен буде володіти складною функціональністю, щоб аналізувати, який саме компонент зараз обробляється, виконувати приведення типу і лише після цього викликати потрібний метод.
Саметут зручно оголосити абстрактний метод у батьківському класі. У нього немає зовнішнього вигляду, але відомо, що він є в його спадкоємця. Тому заголовок методу описується в батьківському класі, тіло методу у спадкоємця своє, а контейнер може спокійно користуватися тільки базовим типом, не роблячи ніяких приведень.
Зверніть увагу - оскільки абстрактний метод не має тіла, після опису його заголовка ставитися крапка з комою. А раз у нього немає тіла, то до нього не можна звертатися, поки його спадкоємці не опишуть реалізацію. Це означає, що не можна створювати екземпляри класу, у якого є абстрактні методи. Такий клас сам оголошується абстрактним.
Клас може бути абстрактним і в тому випадку, якщо в нього немає абстрактних методів, алеповинен бути абстрактним, якщо такі методи є. Розробник може вказати ключове слово abstract у списку модифікаторів класу, якщо хоче заборонити створення екземплярів цього класу. Класи-спадкоємці повинні реалізувати (implements) всі абстрактні методи (якщо вони є) свого абстрактного класу, щоб їх можна було оголошувати неабстрактнимі й породжувати від них екземпляри.
Звичайно, клас не може бути одночасно abstract і final. Це ж вірно й для методів. Крім того, абстрактний метод не може бути private, native, static.
Сам клас може без обмежень користуватися своїми абстрактними методами. З цієї ж метою можна оголошувати змінні типу абстрактний клас. Вони можуть мати значення null або посилатися на об'єкт, породжений від неабстрактного спадкоємця цього класу.
4 Інтерфейси
Концепція абстрактних методів дозволяє запропонувати альтернативу множинного спадкоємства. В Java клас може мати тільки одного батька, оскільки при множинному спадкуванні можуть виникати конфлікти, які заплутують об'єктну модель.
Всі ці проблеми не виникають у тому випадку, якщо успадковуються тільки абстрактні методи від декількох батьків. Навіть якщо успадковано кілька однакових методів, усе одне в них немає реалізації й можна один раз описати тіло методу, яке буде використовуватися при виклику будь-якого з цих методів.
Саме так влаштовані інтерфейси в Java. Від них не можна породжувати об'єкти, алі інші класи можуть реалізовувати їх.
Таким чином, Java надає гнучку й потужну модель об'єктів, що дозволяє проектувати найскладніші системи. Необхідно добрі розбиратися в її основних властивостях та механізмах - успадкування, статичні елементи, абстрактні елементи, інтерфейси, поліморфізм, розмежування доступу та інші. Всі смороду дозволяють уникати дублюючого коду, полегшують розвиток системи, додавання нових можливостей та зміна старих, допомагають забезпечувати мінімальну зв'язність між частинами системи, тобто підвищують модульність. Також вдалі технічні рішення можна багаторазово використовувати в різних системах, скорочуючи й спрощуючи процес їх створення.
Для досягнення таких важливих цілей потрібно не тільки знання Java, алі й володіння об'єктно-орієнтованим підходом, основними способами проектування систем та перевірки якості архітектурних рішень. Платформа Java є основою й вельми зручним інструментом для застосування всіх цих технологій.
