Про об’єкти в Delphi.
Парт тво.
У минулому пості й коментарях, мова йшла про популярну колись систему розробки — Delphi.
Там я сконцентрувався на тому, що Delphi не вміла.
А в цьому трохи скажу про те, як невдала модель розробки самої Delphi занапастила те, що в ній було.
Розробники Delphi вбивчою особливістю позиціонували модель програмування, коли компоненти, як правило, віджети, з панелі компонент перетаскувалися на форму.
Програміст двічі клацав на тому віджеті, наприклад кнопці, а Delphi генерувала не заготовку коду, так званий обробник, який залишалося змінити під свої потреби.
Такий спосіб розробки породив кілька поганих практик розробки — антипатернів.
1. Button1Click — стиль.
Така назва пішла від описаного вище методу розробки.
На картинці типовий приклад.
Що тут не так?
Найбільший гріх тут — це те, що змішали зчитування значень віджетів та бізнес-логіку.
Це призводить до того, що цей код не можна використати повторно і важко супроводжувати.
Цей приклад коротенький, а я бачив обробники на 2–3 екрани.
По-друге, це жахливе форматування.
Редактор Delphi не дуже слідкував за цим, тому як програміст надрукує, так і буде.
Звісно, можна так не писати, але мало хто робив правильно, коли саме середовище провокувало писати таке лайно.
Варто сказати, що розробники Delphi усвідомили проблему і спробували якось виправити ситуацію за допомогою ActionList та ActionManager, але це не прижилось.
2.
Власне, об’єкти.
Delphi з самого початку комплектувалася об’єктною мовою.
Проблема полягала в тому, що програміст перетаскував на форму візуальні і невізуальні компоненти.
Звідси з’явилася асоціація компонентів та об’єктів.
Безумовно, всякий компонент — об’єкт, але не всякий об’єкт — компонент.
Людина бачить панель компонентів і помилково звикає, що то всі її об’єкти.
Вона знає, що можна написати свій об’єкт, але, щоб використати його, потрібно робити якісь маніпуляції з панеллю компонентів.
Особливо це стосується візуальних компонент, бо вже привчені використовувати віджети з панелі компонент і складно будувати інтерфейс у рантаймі.
В результаті або шукають сторонній компонент, або пишуть "лапшу" в обробниках.
У згаданій в минулому пості книжці об’єктний підхід і давався саме в контексті побудови компонент.
А вся інша література привчала до процедурного коду, хоча і з використанням об’єктів.
3.
Інфраструктура.
Попередній пункт породив іншу цікаву проблему.
Люди погано знали інфраструктуру.
Наприклад, мучились з масивами або базою даних там, де можна було використати списки.
На пропозицію скористатись списком не відразу розуміли, що мова йде не про віджет, а про структуру даних 🙂 і т. ін.
Одним словом, зовсім не дивно, що з Delphi з’їхали, в більшості своїй, на C#.
