2.2.3.Виключення

Помилки цього класу виникають у результаті обставин, що не піддаються прямому контролю з боку виконавчої системи Visual FoxPro. Наприклад, програма може припинити виконання через те, що не в змозі знайти необхідний файл. Можливо, що файл вилучений чи переміщений в інший каталог. Природно, що, якщо хтось сторонній зіграв такий злий жарт із програмою, “вийти з достоїнством” з цієї ситуації самостійно вона не може і припиняє роботу. У такому випадку ліпше перед відкриттям файлу спочатку перевірити його наявність.

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

Аж ніяк не з усіма виключеннями можна справитися так просто. У деяких випадках найкраще використовувати процедуру, що викликається в команді ON ERROR⁷, для того щоб зафіксувати в документі стан системи в момент такої виняткової ситуації, “відкотити” поточну трансакцію, закрити всі таблиці і після цього припинити виконання програми.

2.3.Розбивка коду на модулі для мінімізації помилок

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

У Visual FoxPro така розбивка виконується досить просто. Кожен додаток можна розглядати як сукупність окремих задач (tasks). Задача включає (екранні форми для введення даних, звіти чи процедури для обробки даних. Вибір у меню забезпечує запуск тієї чи іншої задачі. Задача, у свою чергу, може бути розділена на підзадачі (subtasks).

Як підійти до розбивки задачі на підзадачі. Нехай обробка даних у екранній формі покупців буде нашою задачею. У рамках цієї задачі обробка окремих полів даних являє собою підзадачі. Окремі поля представляють ім'я покупця, його адреса, номер телефону і т. д. У Visual FoxPro підзадачі асоційовані з об'єктами елементів керування. Якщо поглибитися в подробиці функціонування елементів керування, то можна знайти там окремі методи обробки різних подій, що відбуваються з цим елементом. Ці методи використовуються для реалізації наступних функцій об'єкта:

• установка параметрів об'єкта за замовчуванням;

• визначення прав користувача на доступ до поля;

• перевірка коректності введення даних;

• збереження і витяг даних;

• обробка щигликів кнопкою миші і переміщення покажчика миші;

• відображення зв'язаних з елементом екранних форм;

• передача повідомлень іншим об'єктам, що змушують їх змінити відповідно свої характеристики чи запустити на виконання деякий метод.

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

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

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

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

Технологія об'єктно-орієнтованого програмування дозволяє використовувати і підхід, заснований на принципі спадкування. Можна включити типові функцій у статусі методів у деякий клас, що буде відігравати роль базового для всіх аналогічних по функціях компонентів додатка, наприклад екранних форм. Тоді всі ці методи будуть автоматично успадковуватися всіма похідними класами (і їхніми об'єктами). Прикладом можуть бути об'єкти кнопок керування навігацією по таблицях даних, що формуються як похідні від класу VCR Buttons з бібліотеки фундаментальних класів Visual FoxPro.

Перш ніж включати такий клас у бібліотеку, ретельно протестуйте його і всі зв'язані з ним компоненти. Можна сформувати для цього просту екранну форму і помістити в неї елемент керування що підлягає тестуванню (об'єкт класу). По завершенні тестування (якщо, природно, ви задоволені його результатом) виділите об'єкт і виберіть команду FіleSave As Class. У діалоговому вікні, що з'явиться після цього на екрані, можна привласнити ім'я новому класу і вибрати файл бібліотеки, у яку він буде включений. При цьому буде збережений тільки клас елемента керування без екранної форми, у якій він тестувався. Налагодження ж і модифікація класу, після того як він включений у бібліотеку, — справа вже більш складна.

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

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

Розбивка коду на модулі на рівні задач, крім іншого, дозволяє знову повернутися до ідеї повторного використання коду.