Delphi для професіоналів. Об'єктно-орієнтоване програмування
При описі нового класу важливий розумний компроміс. З одного боку, потрібно приховати від інших методи і поля, що представляють собою внутрішній устрій класу (для цього й придумані властивості). Незначні деталі на рівні користувача об'єкта будуть марні і тільки завадять цілісності сприйняття.
З іншого боку, якщо занадто обмежити того, хто буде породжувати класи-нащадки, і не забезпечити йому достатній набір інструментальних засобів і свободу маневру, то він і не стане використовувати ваш клас.
Області видимості, що визначаються першими трьома директивами, такі.
- Поля, властивості та методи секції public не мають обмежень на видимість. Вони доступні з інших функцій і методів об'єктів як в даному модулі, так і у всіх інших, що посилаються на нього.
- Поля, властивості та методи, що знаходяться в секції private, доступні тільки в методах класу і в функціях, що містяться в тому ж модулі, що і описуваний клас. Така директива дозволяє повністю приховати деталі внутрішньої реалізації класу. Властивості і методи з секції private можна змінювати, і це не буде позначатися на програмах, які працюють з об'єктами цього класу. Єдиний спосіб для кого-то другого звернутися до них - переписати заново створений вами модуль (якщо, звичайно, доступні вихідні тексти).
- Поля, властивості та методи секції protected також доступні тільки всередині модуля з описуваних класом. Але - і це головне - вони доступні в класах, які є нащадками даного класу, в тому числі і в інших модулях. Такі елементи особливо необхідні для розробників нових компонентів - нащадків вже існуючих. Залишаючи свободу модернізації класу, вони все ж приховують деталі реалізації від того, хто тільки користується об'єктами цього класу.
Розглянемо приклад, який ілюструє три варіанти областей видимості.
Лістинг 1.1. Приклад завдання областей видимості методів
unit First; | unit Second;
TFirstObj = class | TSecondObj = class (TFirstObj>
private | procedure Method4;
procedure Methodl; | end;