Об’єктно-орієнтоване програмування в CTD – потужний інструмент для бази типових проектних рішень при побудові інформаційних систем, Різне, Програмування, статті

Зміст



В даній статті дано короткий опис особливостей об’єктно-орієнтованого програмування (ООП) на базі популярних засобів розробки інформаційних систем CTD2000 – Centura Team Developer 2000. ООП в CTD забезпечує необхідний професіоналізм програмних проектів, високий рівень взаємозамінності і основу для створення типових проектних рішень при розробці та реалізації інформаційних систем найвищої складності. Сподіваємося, що даний матеріал дозволить створити правильне уявлення про можливості програмного продукту і вибрати його для вирішення своїх завдань в сфері інформаційних технологій.


Введення


Об’єктно-орієнтоване програмування (іноді і більш точно, говорять про об’єктно-орієнтованому проектуванні програмного забезпечення) є базою для створення складних інформаційних систем і основою для широкого впровадження інформаційних технологій. У зв’язку з цим всі засоби програмування, орієнтовані на професіоналів, включають ці механізми. У мову SAL, Який є основою CTD, були спочатку включені можливості підтримки об’єктного підходу.


Стандартні і призначені для користувача класи, і створювані на їхній базі об’єкти (візуальні та інтерфейсні), призначені для підвищення технологічності процесу створення інформаційних систем, спрощення процесу їх супроводу та побудови бібліотек типових проектних рішень для подальшого застосування. Фірма Centura/Gupta у всіх своїх рішеннях, про що я говорив і в інших статтях, і тут знайшла компроміс (“золоту середину”) між складністю використання та широкими можливостями ООП. Незважаючи на наявність всіх теоретичних атрибутів ООП (успадкування, інкапсуляція і поліморфізм) знайдені конструктивно прості рішення, які дозволяють ефективно застосовувати ці механізми, як користувачу новачкові, так і досвідченому програмісту, причому останній буде володіти всіма необхідними засобами для вирішення будь-яких поставлених завдань. Це досягається, зокрема, за рахунок того, що проведено попереднє поділ класів за типами (Виділені: функціональні, віконні та дочірні класи – див. нижче), а також використовується структуризація описів класів і об’єктів.


Основи ООП в CTD


Мова SAL і система розробки CTD підтримують всі типові механізми ООП:



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


Класи CTD і їх типи


Наслідком спеціалізації в CTD стало виділення трьох типів класів:



Всі класи додатка описуються в розділі глобальних описів (Global Declarations – Class Definitions), що показано в прикладі нижче на фрагменті OUTLINE:



У даному прикладі описані (докладний опис приховано): функціональний клас – cls1; віконні класи відповідних підтипів – clsMDIFrame1, clsDataEntryForm і clsDlgStandard; дочірній віконний клас – clsDatabaseField і головний віконний клас – clsAbstract. Спеціалізація типів класів в CTD дозволяє спростити опис інтерфейсу і застосування механізмів наслідування. Зокрема: новий ОК може створюватися лише на базі вже описаного ГЗК або іншого ОК. Можна також для включення нових функцій використовувати і ФК.


Опис класу в CTD


Опис класу в CTD структуровано і залежить від типу класу. Нижче наведено опис ОК типу Form Window Class (віконні класи мають безліч стандартних підтипів):



Ім’я класу задається в заголовку (clsDBWindow), надалі воно використовується для опису та створення об’єктів даного класу. Розділ Derived From визначає список базових класів для наслідування. В частини Menu, Tool Bar і Contents визначаються відомі для SAL елементи опису вікна. У розділі Class Variables задаються змінні класу, а розділі Instance Variables задаються індивідуальні змінні кожного примірника об’єкта даного класу. У частині Functions і Message Actions задаються функції-методи класу і обробники повідомлень. Для стандартних типів класів структурізованние зміст може відрізнятися.


Спадкування класів в CTD


Розрізняють такі види спадкування:



При спадкуванні породжений клас “вбирає” в себе всі функції і обробники повідомлень з базових класів. Приклад множинного успадкування показаний нижче:



Приклад множинного успадкування для класу cDesktopListBox. Він успадковується від класів cOutline і cListBoxExtension. На жаль, обмежені рамки цієї статті не дозволяють показати всі можливості та особливості спадкування в CTD.


Перевантаження функцій і подій


Перевантаження функцій і подій на увазі використання в класі спадкоємця можливості зміни алгоритмів закладених у функції або реакції на повідомлення (події). У CTD, однак, існує ще додаткова можливість перевантаження функцій і подій: в самому об’єкті при його описі (воно теж структуровано на основі структури використовуваного класу) також можна виконати перевантаження, задавши нову реакцію на таке ж повідомлення (messages actions) або задати функцію з тим же ім’ям, що і в класі.


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




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


Області видимості змінних об’єктів і класів


За замовчуванням змінні об’єкта доступні тільки в обробниках об’єктів, однак, за допомогою кваліфікованих посилання можна через об’єкт або через клас отримати доступ до змінних об’єкта. Приклад опису змінних об’єкта дано нижче:



Посилання на змінну об’єкта може бути виконана через клас і покажчик на вікно:



Посилання на змінну об’єкта може бути виконана і через об’єкт:



Змінні класу є загальними для всіх об’єктів класу і можуть розділятися всіма об’єктами цього класу, вони представляються в єдиному екземплярі (це аналог статичного атрибута класу). Приклад описи таких змінних дан нижче:



Імена цих змінних не повинні перевантажуватися всередині класу і в об’єктах класу. Для доступу до об’єкта в його методах може бути використано спеціальне ключове слово – this. Ця змінна представляє собою посилання на поточний об’єкт, тому їй необхідно користуватися для доступу до змінних об’єкта.



Якщо об’єкт може отримувати значення (наприклад, поле даних у вікні), то можна скористатися стандартною змінної – MyValue. Вона повинна використовуватися, тому що в класах недоступні імена майбутніх об’єктів. Тому потрібно писати:



Однак, невірної буде в цьому випадку в методах класу такий запис:



Так як змінна df1 ще не відома при описі класу.


Функціональні класи – ФК


Функціональні класи використовуються для опису змінних (структур), набору функцій, а також для базових класів при спадкуванні у віконних класах. Об’єкти функціональних класів не можуть обробляти повідомлення і реагувати на події. Опис функціональних класів має вигляд, представлений нижче (даний опис не розкрито повністю):



Змінні класу (Class Variables) розділені між усіма створюваними об’єктами класів. Функції класу (Functions) доступні тільки при створенні об’єкту класу. Змінні об’єктів (Instance Variables ) Безпосередньо представляють дані об’єкта. ФК можуть бути базовими для інших ФК або для віконних класів і для ГЗК. В останньому випадку будуть успадковуватися і функції класу і змінні.


Віконні класи ОК і головні віконні класи


Віконний клас є стандартним класом WINDOWS. Він може бути базовим для іншого віконного класу (причому, типи віконних класів повинні збігатися) і бути спадкоємцем ФК. Приклад опису ОК був вже приведений вище. На відміну від ФК в ньому присутній розділ опису реакцій на повідомлення – Message Action, в якому описуються дії при вступі повідомлень до даного об’єкту (SAM_ *). Типи віконних класів: форми, MDI форми, таблиці даних, вікна діалогу, дочірні класи (всі стандартні типи об’єктів).


В SAL передбачено створення головних віконних класів (General Window Class). Від ОК ці класи не обов’язково представляють візуальні об’єкти, однак можуть обробляти повідомлення. Приклад опису ГЗК наведено нижче:



ГЗК може бути базою для іншого ГЗК і для ОК. Він схожий на ФК, але на відміну від нього може обробляти повідомлення і події. ГЗК може успадковуватися від ФК, але не може бути для нього базовим. Створювати об’єкти на основі ГЗК не можна. ГЗК забезпечує множинне спадкування в ланцюжках класів. Можна успадковувати від нього ОК і тільки потім створювати об’єкти. Головні віконні класи використовуються як допоміжні для ієрархічного успадкування. У загальноприйнятому розумінні це абстрактні класи.


Підключення класів в додаток (APL)


Класи можна описати безпосередньо в додатку в розділі глобальних описів Classes. Класи можуть бути описані в будь-якому порядку. Можна підключати класи також з бібліотек – APL (APD). В цьому випадку CTD автоматично їх розпорядженні в потрібних розділах, причому розподіляються всі частини бібліотек. Бібліотека може бути створена в середовищі CTD або згенерована за допомогою АХ Explorer. Бібліотека підключається в глобальному розділі опису, наприклад:


В даному випадку бібліотека класів інтерфейсу (Visual Toolchest) підключається до програми, а всі класи, описані в ній, автоматично переносяться в розділ класів – Classes.


Створення та опис об’єктів


В залежності від типу класу об’єкти можуть бути описані різних розділах програми. Об’єкти функціональних класів можуть бути описані в будь-якому розділі типу Variables (глобальному, вікна, функції, параметрів функції і вікна). Об’єкти класів, створені на основі ОК загального вигляду (вікна, форми, вікна діалогу) поміщаються в розділах Windows глобального опису або створюються динамічно за допомогою функції SalCreateWindow. Дочірні віконні об’єкти описуються в розділі Contents віконних об’єктів загального виду. Загальний синтаксис опису і приклад наведено нижче.


Синтаксис опису об’єктів на основі нових класів:

<ClassName>: <ObjectName>


Приклади опису дочірніх віконних, функціональних і загальних віконних об’єктів:



При описі об’єктів ОК стають доступними всі розділи опису, відповідні даному типу класу. Крім того, стають доступними для редагування загальні атрибути, а якщо була передбачена спеціальна клас-DLL для редагування інших параметрів об’єкту, то викликаються спеціальні вікна діалогу для редагування властивостей об’єктів даного конкретного класу, які фіксуються в OUTLINE. Останнє в більшою мірою характерно для АХ об’єктів.


Для роботи з об’єктами класів в CTD передбачені спеціальні функції:



Можливості динамічного опису вікон і дочірніх об’єктів


У CTD немає прямих механізмів динамічного створення дочірніх об’єктів вікон. У деяких системах це необхідно для побудови динамічного інтерфейсу програми. Однак існують прийоми, які забезпечують такі можливості. Їх ми пояснимо нижче. Об’єкти ж функціональних класів можуть створюватися динамічно за допомогою оператора new. Приклад такого створення показаний нижче:



Над однорідними змінними функціональних класів допустимі також операції присвоювання:



Віконні об’єкти можуть бути динамічно створені за допомогою відомої функції SalCreateWindow. В цьому випадку достатньо вказати тип створюваного вікна. Можна в такому разі створювати кілька екземплярів вікон одного і того ж типу.


Для забезпечення динаміки створення дочірніх об’єктів існує два способи:


перший – Це використання механізмів AX об’єктів, для цього передбачені спеціальні функції в CTD;
друга – Це опис вікон загального вигляду, що містять один дочірній об’єкт і співпадаючих за розміром з дочірнім об’єктом.


Далі задача зводиться до відомої, так як вікна можна створювати динамічно (див. вище). Останній спосіб не є витонченим, але все-таки є виходом для вирішення проблеми.


Функції класу


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


Різні варіанти виконання функцій класів через клас і об’єкти:



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


Автоматизація створення класів в CTD


У CTD передбачені засоби автоматизованого створення нових класів. За допомогою Wizards ви можете вибрати базові класи для нового класу, налаштувати при необхідності параметри. Серія автоматично викликаються вікон допоможе вам це зробити. Після завершення автоматизованого створення класу його можна правити вручну. Так як при спадкуванні важливий тип нових класів буде автоматично проведена перевірка правильності створеного знову класу.


АХ і СОМ в CTD


У CTD вбудовані спеціальні механізми створення і підключення AX і СОМ об’єктів. За допомогою спеціальної утиліти (АХ Explorer) ви можете підключити та використати всі об’єкти, встановлені на вашому комп’ютері. Для створення СОМ об’єктів та їх реєстрації також ви можете скористатися майстром підказок, причому генерація опису та всіх необхідних нових класів виконується в автоматичному режимі. Більш докладно про використання цих режимів ви можете дізнатися у статті на нашому сайті (стаття по AX і СОМ на сайті).


Типові проектні рішення на базі ООП


Класи і об’єктно-орієнтоване програмування можуть ефективно використовуватися для створення системи типових проектних рішень при створенні інформаційних систем самої різної складності. Я вже зазначав, що CTD (а раніше і SQLWindows) спочатку були спроектована як об’єктно-орієнтована система програмування. В її перші версії були включені (і до цих пір використовуються) бібліотеки класів Quick Objects (QO), механізми побудови шаблонів, бібліотека Visual Toolchest (VT). Далі при розвитку CTD система доповнювалася також через набори та механізми класів: WEB Developer реалізований на їх основі; підключені бібліотеки доступу до інтернет (mail, HTTP і т.д.); реалізовані реплікації в БД – Replication Agent. Думаю, що подальший розвиток CTD триватиме в такому ж напрямку: підключення нових класів та бібліотек їх підтримують.


Для кожного певного класу систем можуть бути створені бібліотеки та підключені до додатків за допомогою інтерфейсу класів і об’єктів. Це може бути реалізовано в рамках навіть невеликих фірм, що виконують проекти з розробки і супроводу інформаційних систем. Природно, початкові витрати на розробку типових проектних рішень будуть більше, проте слід очікувати швидкої окупності при такому підході. Як приклади можна вказати створення спеціальних класів для роботи з БД, взаємодії з інтернет, організації динамічного інтерфейсу та формування вихідних документів. Приклади вдалого застосування типових рішень на базі ОПП в CTD існують.


Що краще універсальне і спеціалізоване ООП?


Безсумнівно, що викладена в цьому матеріалі інформація обмежена рамками статті та не може забезпечити повне уявлення щодо використання ООП в CTD. Крім того, поза сумнівом, знайдуться такі програмісти, яким не сподобатися підходи до ООП реалізовані в продуктах Centura. Я навіть очікую хвилю критики тих, хто не дуже детально знайомий з можливостями продукту. Проте, можу стверджувати, що, незважаючи на відсутність повної універсальності в CTD, Такий варіант застосування ООП є багато в чому кращим, особливо для випадку масового виробництва інформаційних систем, необхідності одночасного супроводу декількох проектів. З цих позицій вважаю, що такий підхід до ООП, заснований на спеціалізації у багатьох випадках більш ефективний, ніж універсальний. Навіть у багатьох універсальних системах програмування зараз намагаються розділити опису візуальних і не візуальних об’єктів, опрощая способи цього опису і наочність використання ООП. Не буду наводити приклади і називати системи, побоюючись необгрунтованої критики, хоча впевнений, що найближчим часом у багатьох системах будуть зроблені кроки для спрощення опису класів і об’єктів для конкретних сфер застосування.


Висновок


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


Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*