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