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

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

type

TaClass = class

IntField: Integer; Function GetField: Integer;

Procedure SetField (Value: Integers);

Property IntegerValue: Integer read GetField

write SetField;

end;

У контексті програми властивість поводиться як звичайне поле. Наприклад, ми могли б написати такі оператори:

var

aClass: TaClass;

Value: Integer;

begin

aClass := TaClass.Create; { Обов'язкове звертання до

конструктору перед звертанням до поля чи властивості!} aClass.IntegerValue := 0;

Value := aClass.IntegerValue;

aClass.Destroy; // Видалення непотрібного об'єкта

end;

Більш того, можливий і такий оператор присвоювання:

aClass.IntField := NewValue;

Різниця між цим оператором і оператором

aClass.IntegerValue := NewValue;

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

IbOutput.Caption := 'Рядок';

Властивість Caption компонента Label викликає метод setText, що не тільки запам'ятовує рядок символів у внутрішньої перемінний, але і здійснює промальовування мітки з новим текстом.

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

type

TaClass = class IntFiled: Integer;

Procedure SetFieid (Value: Integers;

Property IntegerValue:

Integer read IntFiled write SetFieid;

end;

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

1.2 Оголошення класу

Любою знову створюваний клас може містити секції (розділи), обумовлені зарезервованими словами published (опубліковані), private (закриті), protected (захищені), public (доступні) і automated (автоматизовані). Усередині кожної секції спочатку визначаються поля, а потім - методи і властивості.

Секції визначають області видимості елементів опису класу. Секція public не накладає обмежень на область видимості полів, що перелічуються в ній, методів і властивостей - їхній можна викликати в будь-якому іншому модулі програми. Секція published також не обмежує область видимості, однак у ній перелічуються властивості, що повинні бути доступні не тільки на етапі виконання, але і на етапі конструювання програми (тобто у вікні Інспектора об'єктів). Секція published використовується тільки при розробці нестандартних компонентів. Замітаю, що середовище Delphi поміщає опису компонентів, вставлених у форму, у спеціальну секцію без назви, що розташовується відразу за заголовком класу і продовжується до першої оголошеної секції. Ця секція - published. Програмісту не слід поміщати в неї власні елементи опису чи класу видаляти з її елементи, уставлені середовищем. Секція private звужує область видимості до мінімуму: закриті елементи описи доступні тільки усередині методів даного класу і підпрограмах, що знаходяться в тім же модулі, де описаний клас. Елемент, оголошений у секції private, стає недоступним навіть найближчим нащадкам класу, якщо вони розміщаються в інших модулях. Секція protected доступна тільки методам самого класу, а також будь-яким його нащадкам, незалежно від того, чи знаходяться вони в тім же чи модулі ні. Нарешті, секція automated використовується тільки для оголошення властивостей і методів, що будуть додані до так називаного інтерфейсу OLE-об'єктів Автоматизації; область видимості членів цієї секції не обмежена.

У Object Pascal дозволяється скільки завгодно раз повідомляти будь-як секцію, причому порядок проходження секцій не має значення. Будь-яка секція може бути порожній.

Наступний фрагмент коду пояснює області видимості.

Unit Unit1;

Interface

Uses Controls, Forms;

type

TForm = class(TForm)

Buttoni: TButton; // Ця секція обслуговується Delphi

// Її елементи доступні усім // Ця секція доступна в модулі Uniti

private FIntField: Integers Procedure SetValue(Value: Integers); Function GetValue: Integer; published // Ця секція доступна в будь-якому модулі

Property IntField: read GetValue write SetValue;

protected // Ця секція доступна класам-нащадкам

Procedure Proc1;

public // Ця секція доступна в будь-якому модулі Procedure Proc2;

end;

var

Formi: TForm1;

Implementation Procedure TForm.Proc1 ;

Buttoni.Color := clBtnFace;1

// Так можна

FIntField := 0;

// Так можна

IntField := 0;1

// Так можна Proc1;

// Так можна Proc2;1

// Так можна

end;

begin

Form1.Button1.Color := clBtnFace; // Так можна

Form1.FIntField := 0; // Так можна

Form1.IntField := 0; // Так можна Form1.Proc1; // Так не можна! Form1.Proc2; // Так можна

end.

Unit Unit2;

Interface

Uses Controls, Unit1;

type

TForm2 = class(TFormI) Button2: TButton;

Procedure Button2Click(Sender: TObject);

end;

var

Form2: TForm2;

Implementation

Procedure TForm2.Button2Click(Sender: TObject);

begin

Buttoni.Color := clBtnFace; // Так можна

Fіn'tFіеld := 0; // Так не можна!

IntField := 0; // Так можна

Proc1; // Так можна

Proc2; // Так можна

end;

begin

Form1.Buttoni.Color := clBtnFace; // Так можна

Form1.FIntField := 0; // Так не можна!

Form1.IntField := 0; // Так можна

Form1.Proc1; //Так не можна!

Form1.Proc2; // Так можна

end.

При оголошенні класу-нащадка дозволяється переміщати елементи класу з однієї області видимості в іншу. Для попереднього приклада припустиме таке оголошення:

type

TForm2 = class(Tform1)

Public

Procedure Proc1;

end;

Після цього в модулі unit2 можливо таке звертання:

Form2.Proc1;

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

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

Модульність

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

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

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

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

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

Ієрархія

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

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

Ієрархія - це упорядкування абстракцій, розташування їх по рівнях.

Основними видами ієрархічних структур стосовно до складних систем є структура класів (ієрархія "is-a") і структура об'єктів (ієрархія "part of").

Приклади ієрархії: одиночне спадкування. Важливим елементом об’єктно-орієнтованих систем і основним видом ієрархії "is-a" є згадувана вище концепція спадкування. Спадкування означає таке відношення між класами (відношення батько/нащадок), коли один клас запозичає структурну чи функціональну частину одного чи декількох інших класів (відповідно, одиночне і множинне спадкування). Іншими словами, спадкування створює таку ієрархію абстракцій, у якій підкласи успадковують будівлю від одного чи декількох суперкласів. Часто підклас добудовує чи переписує компоненти вищестоящого класу.

Семантично, спадкування описує відношення типу "is-a". Наприклад, ведмідь є ссавець, будинок є нерухомість і "швидке сортування" є алгоритм, що сортує. Таким чином, спадкування породжує ієрархію "узагальнення-спеціалізація", у якій підклас являє собою спеціалізований окремий випадок свого суперкласу.

Типізація

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

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

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