Це дуже непростий і спірне питання. В "чистих" язи-
ках, що використовують підхід OOP, статичні методи не суті-
ют; всі методи є віртуальними. І прихильник "чистого"
підходу OOP міг би сказати, що всі методи в нашій ієрархії
об'єктів повинні бути віртуальними саме з тієї причини, що
віртуальні методи стоять на першому місці. Такий аргумент мож-
але було б визнати справедливим, але ще більше істини в тому,
що робити всі методи тільки віртуальними просто непрактично
- Принаймні, тоді, коли Ви програмуєте на Turbo
Pascal.
На наш погляд, є два переконливих аргументу на користь
того, щоб скрізь, де це тільки можливо, використовувати ста-
тичні методи. По-перше, інтелектуальний компонувальник
Turbo Pascal не може скасовувати не використовуються віртуальні ме-
тоды, а тільки не використовуються статичні методи; простий акт
введення об'єкта даного типу призводить до того, що в програму
повинні бути скомпоновані всі віртуальні методи цього об'єктивним
та. І по-друге, чим більше віртуальних методів має об'єкт,
тим більші його таблиця віртуальних методів VMT: об'єкт,
що має 100 віртуальних методів, що використав би більше 400
байт простору в сегменті даних. У системі Object
Professional немає жодного об'єкта, який би мав так багато
віртуальних методів, але якщо б всі методи були віртуальними,
в ній би був не один такий об'єкт.
Вважаючи, що з практичної точки зору неможливо у
всіх випадках застосовувати тільки одні віртуальні методи, ми
стоїмо на тих позиціях, що доцільно створювати Віртуаль-
тивні методи тільки в наступних трьох випадках:
а) якщо ми знаємо, що він повинен бути скасований об'єктивним
тому-нащадком,
б) якщо метод призначений для того, щоб бути скасований-
вим, і для цієї мети й існує,
в) якщо в самій природі методу закладена можливість то-
го, що бажано його скасувати в об'єкті-нащадку.
Покажчики процедур проти похідних типів.
Ще один концептуально спірне питання. Розглянемо слу-
чай, коли для деякого об'єкта необхідно забезпечити
засіб, що дозволяє програмісту передавати таку інформа-
цію для об'єкта, яка не завжди буває відома на момент
компілювання. Наочним прикладом такого об'єкта є
"PickList" ( "Спісок_Подбора") в модулі OPPICK: він повинен
забезпечити засіб, що надасть Вам можливість "з-
общіть "йому, які елементи є у списку підбору.
Прихильник "чистого" методу міг би сказати, що для вирішення-
ня цієї проблеми слід забезпечити фіктивний віртуальний
метод, який, як передбачається, буде повертати необ-
дімую інформацію, і нехай потім програміст створює виробниц-
ний тип, який скасовує цей метод. Але такий підхід порож-
дає дві проблеми. Перша полягає в тому, що було б
прикро, якби КОЖЕН раз, коли виникає потреба ис-
користуватися, наприклад, об'єкт PickList, довелося створювати
похідний тип, особливо в тому випадку, якщо все, що Вам
дійсно потрібно - це написати функцію для відбудовн-
лення рядки на основі номера елемента. Друга проблема сос-
тоит в тому, що при цьому в більшості випадків виключається
можливість використання одного й того самого об'єкта PickList
для відображення на екрані різних списків.
Ми вважаємо за краще прийняти компромісне рішення. У подоб-
них випадках дійсно є віртуальні методи, які
Ви можете відмінити, якщо захочете. Але крім цього існують
такі кошти, які за допомогою покажчика процедури задають
ту підпрограму, написану користувачем, яка потрібна для
виконання операції. Реалізація віртуального методу за умовчанням
чанію просто використовує цей покажчик процедури, щоб дзв-
вать Вашу підпрограму.
Конструктори і деструктори.
У системі Object Professional відповідно до угоді-
нями фірми Borland прийнято для конструкторів використовувати
ім'я "Init" ( "Початковий"), а для деструкторів - ім'я "Done"
( "Закінчений"). Більшість об'єктів також має конструктор
з ім'ям "Load" ( "Завантаження"), який використовується для заг-
Рузком об'єкта з потоку (ще більше на потоках через момент
?) - Згідно з іншим угодою фірми Borland.
Для забезпечення уніфікації кожен об'єкт в ієрархії име-
ет деструктор з ім'ям Done, навіть якщо він і не потрібний, і ці
деструктори ніколи не приймають ніяких параметрів. Що ка-
саєти конструкторів, однак, то тут існують деякі
варіанти.
Конструктор Init завжди приймає стільки параметрів,
скільки можливо. Якщо за певних обставин ба-
тельно передати більше параметрів, існує друга конс-
труктор з ім'ям "InitCustom" ( "Начальная_Настройка"), кото-
рий їх приймає (додатково до параметрів, які
передані конструктору Init). В об'єкті, що має конструктор
InitCustom, конструктор Init зазвичай використовується для виклику
конструктора InitCustom, який, у свою чергу, за промовчу-
нію передає значення туди, де це необхідно.
Існує кілька об'єктів, які мають також і
інші конструктори - наприклад, "MemoFile" ( "Файл_Памяті")
(модуль OPMEMO) і PickList (модуль OPPICK) - але при цьому в
більшості випадків їхні імена починаються з "Init", і вони при-
нітрохи такі ж параметри, як і конструктор Init.
Використання динамічно розподіляє області.
Всі об'єкти в бібліотеці використовують спільні розбраті-
виділяється область для зберігання даних в тих випадках, коли мо-
жет змінюватися розмір даних, а також у тих випадках, коли
може змінюватися кількість елементів даних (наприклад, спи-
сік полів з використанням покажчиків у екрані введення даних і
список елементів в меню). Такий підхід забезпечує ефектив-
ве використання наявної у Вашому розпорядженні пам'яті, але
він також володіє одним можливим істотним недоліком:
він може викликати в певних випадках проблеми фрагментіро-
вання динамічно розподіляє області.
Найчастіше проблеми фрагментованість динамічно розбраті-
ділить області можуть виникнути при використанні програм,
які створюють і руйнують безліч об'єктів без будь-ли-
бо певного порядку (найкращим прикладом таких програм є при-
ляется DESKPOP), і особливо це відноситься до таких програм,
які дозволяють користувачеві "розорювати" вікна на весь ек-
ран і змінювати їх розміри. Ми багато міркували над цим воп-
росомах, сподіваючись знайти спосіб, щоб уникнути всієї цієї сово-
купності проблем, але прийшли до висновку, що всі можливі
рішення є або надто незграбними, або занадто на-
вязчівимі, або занадто ризикованими. Єдине розумне
рішення цієї проблеми ми бачимо в тому, щоб фірма Borland
забезпечила програму управління динамічно розподіляє
областю, за допомогою якої можна здійснювати очищення пам'яті
більш-менш є зручно і зрозуміло.
Тепер перейдемо до менш песимістичним та більш загального
питання. Модуль OPROOT, який використовується більшістю
інших модулів, що містять об'єкти, встановлює функцію
помилки динамічно розподіляє області, яка "відповідаючи-
ет "за те, щоб всі аварійно що завершилися виклики New або
GetMem повертали "порожнє" значення ( "Nil"). Якщо необхідно,
Ви можете скасувати цей режим шляхом встановлення власної
функції помилки динамічно розподіляє області, але перш за
ніж це зробити, необхідно переконатися, що Ви ясно собі
уявляєте можливі наслідки. Якщо це тільки можли-
але, ми рекомендуємо Вам писати свою програму так, щоб вона
працювала за цих умов. Єдине, що Ви можете сде-
робити, щоб полегшити свою роботу, це використовувати функції
GetMemCheck і FreeMemCheck в модулі OPROOT кожного разу, коли
Вам необхідно розмістити пам'ять або анулювати розміщення
пам'яті з динамічно розподіляє області; це те, що мо-
гут робити всі Ваші об'єкти. Докладні відомості про вико-
вання цих функцій наведено в документації, яка описує мо-
дуль OPROOT.
Обробка помилок.
Всі об'єкти більш високого рівня в бібліотеці побудовані
так, щоб видавати повідомлення про всі помилки, які
зустрічаються після того, як об'єкт був введений в центральну
програму обробки помилок. Ця програма обробки помилок
передає як код помилки, так і (звичайно) прийняте за замовчуванням
повідомлення про помилки, що дозволяє програмі обробки
помилок вивести на екран або типове повідомлення про помилки,
або повідомлення, модифіковане відповідно до потребнос-
тями користувача. Помилки, які зустрічаються в конструктив-
рах (перш ніж є можливість вказати програму обра-
лення помилок), зберігаються в глобальній змінній InitStatus,
оголошеної в модулі OPROOT. Більш докладні відомості, що стосуються-
щіеся способів обробки помилок, наведені в документації,
описує об'єкт "CommandWindow" ( "Окно_Команд") (модуль
OPWINDOW) та в додатку D ( "Коди помилок").
Обробка команд і клавіатури.
Всі об'єкти в бібліотеці, які діють на основі
команд, що вводяться з клавіатури, використовують об'єкт з ім'ям
"CommandProcessor" ( "Командний_Процессор") для того, щоб
перетворити натискання на клавіші в команди. Для того, щоб
це було можливо, відповідний об'єкт передає об'єкту
CommandProcessor таблицю команд, що представляє собою масив
особливого формату, який встановлює залежності між пос-
ледовательностямі клавіш і командами. Кожна команда в біблії-
набряку відповідає унікальному коду. Використання кодів ко-
Манд і таблиць команд не тільки дозволяє програмі під час
свого виконання модифіковані і додавати призначення кла-
виш, але також і створювати окремі програми конфігурірова-
ня, які дозволяють користувачеві модифіковані призна-
вання. Докладні відомості, що стосуються обробки команд,
наведено в документації, яка описує модуль OPCMD.
Об'єкт CommandProcessor також реалізує деякі прог-
раммние кошти звернення до підпрограм ( "hook"), причому
найбільш важливе з них забезпечує можливість вказати, ка-
кая підпрограма повинна бути викликана в той момент, коли
натискання на відповідну клавішу. Це засіб
дозволяє виконувати "фонові завдання" в той час, поки введення
команди з клавіатури ще не зроблений.
Кольори екрану і об'єкти ColorSet.
У системі Object Professional всі об'єкти, які ви-
виконується екранний введення/виводу ( "I/O" - від "input/output"), раз-
розроблені так, щоб полегшити написання програм, автомати-
но враховують відмінності між кольоровими і монохромними
системами. Тому коли об'єкту необхідно вказати атрибути
відображення інформації на екрані, цей об'єкт запитує два
атрибуту: один для кольорових систем і інший - для монохромних.
Після цього об'єкт буде використовувати просту підпрограму в
модулі OPCRT для того, щоб вибрати відповідний атрибуту
відображення в даній ситуації.
Ці об'єкти також розроблені таким чином, що позво-
ляють, щоб вибрані Вами колірні характеристики зображення-
ня були зосереджені в єдиній структурі даних в об'єкті з
ім'ям ColorSet, який може бути багато разів використаний в
Протягом всього часу роботи програми. Коли Ви вводите об'єк-
ект, який використовує безліч різних атрибутів відображення,
то Ви просто передаєте йому ім'я Вашого об'єкту ColorSet. Опі-
саніе об'єкта ColorSet і більш докладні відомості про те, для
чого він використовується, наведені в документації, яка описує
модуль OPCRT.