Про об’єкти в Delphi. Парт тво
Jul. 9th, 2021 08:46 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
baluВ минулому пості й коментарях, мова йшла про популярну колись систему розробки — Delphi. Там я сконцентрувався на тому, що Delphi не вміла. А в цьому трохи скажу про те, як невдала модель розробки самої Delphi занапастила те, що в ній було.
Розробники Delphi вбивчою особливістю позиціонували модель програмування, коли компоненти, як правило віджети, з панелі компонент перетаскувалися на форму. Програміст двічі клацав на тому віджеті, наприклад кнопці, а Delphi генерувала заготовку кода, так званий обробник, який залишалося змінити під свої потреби. Такий спосіб розробки породив кілька поганих практик розробки — антипатернів.
1. Button1Click — стиль. Така назва пішла від описаного вище методу розробки. На картинці типовий приклад.
Що з тут не так? Найбільший гріх тут, це те, що змішали зчитування значень віджетів та бізнес-логіку. Це призводить до того, що цей код не можна використати повторно і важко супроводжувати. Цей приклад коротенький, а я бачив обробники на 2–3 екрани.
По-друге, це жахливе форматування. Редактор Delphi не дуже слідкував за цим, тому як програміст надрукує, так і буде. Звісно, можна так не писати, але мало хто робив правильно, коли саме середовище провокувало писати таке лайно.
Варто сказати, що розробники Delphi усвідомили проблему, і спробували якось виправити ситуацію за допомогою ActionList та ActionManager, але це не прижилось.
2. Власне, об’єкти. Delphi з самого початку комплектувалася об’єктною мовою. Проблема полягала в тому, що програміст перетаскував на форму візуальні і невізуальні компоненти. Звідси з’явилася асоціація компонентів та об’єктів. Безумовно, всякий компонент — об’єкт, але не всякий об’єкт — компонент. Людина бачить панель компонентів і помилково звикає, що то всі її об’єкти. Вона знає, що можна написати свій об’єкт, але, щоб використати його це з потрібно робити якісь маніпуляції з панеллю компонентів. Особливо це стосується візуальних компонент, бо вже привчені використовувати віджети з панелі компонент і складно будувати інтерфейс в рантаймі. В результаті або шукають сторонній компонент, або пишуть лапшу в обробниках.
У згаданій в минулому пості книжці об’єктний підхід і давався саме в контексті побудови компонент. А вся інша література привчала до процедурного коду, хоча і з використанням об’єктів.
3. Інфраструктура. Попередній пункт породив іншу цікаву проблему. Люди погано знали якусь інфраструктуру. Наприклад, мучились з масивами або базою даних там, де можна було використати списки. На пропозицію скористатись списком не відразу розуміли, що мова йде не про віджет, а про структуру даних :) і т.і.
Одним словом, зовсім не дивно, що з Delphi з’їхали, в більшості своїй, на C#.
Розробники Delphi вбивчою особливістю позиціонували модель програмування, коли компоненти, як правило віджети, з панелі компонент перетаскувалися на форму. Програміст двічі клацав на тому віджеті, наприклад кнопці, а Delphi генерувала заготовку кода, так званий обробник, який залишалося змінити під свої потреби. Такий спосіб розробки породив кілька поганих практик розробки — антипатернів.
1. Button1Click — стиль. Така назва пішла від описаного вище методу розробки. На картинці типовий приклад.
Що з тут не так? Найбільший гріх тут, це те, що змішали зчитування значень віджетів та бізнес-логіку. Це призводить до того, що цей код не можна використати повторно і важко супроводжувати. Цей приклад коротенький, а я бачив обробники на 2–3 екрани.
По-друге, це жахливе форматування. Редактор Delphi не дуже слідкував за цим, тому як програміст надрукує, так і буде. Звісно, можна так не писати, але мало хто робив правильно, коли саме середовище провокувало писати таке лайно.
Таке форматування дещо краще
Варто сказати, що розробники Delphi усвідомили проблему, і спробували якось виправити ситуацію за допомогою ActionList та ActionManager, але це не прижилось.
2. Власне, об’єкти. Delphi з самого початку комплектувалася об’єктною мовою. Проблема полягала в тому, що програміст перетаскував на форму візуальні і невізуальні компоненти. Звідси з’явилася асоціація компонентів та об’єктів. Безумовно, всякий компонент — об’єкт, але не всякий об’єкт — компонент. Людина бачить панель компонентів і помилково звикає, що то всі її об’єкти. Вона знає, що можна написати свій об’єкт, але, щоб використати його це з потрібно робити якісь маніпуляції з панеллю компонентів. Особливо це стосується візуальних компонент, бо вже привчені використовувати віджети з панелі компонент і складно будувати інтерфейс в рантаймі. В результаті або шукають сторонній компонент, або пишуть лапшу в обробниках.
У згаданій в минулому пості книжці об’єктний підхід і давався саме в контексті побудови компонент. А вся інша література привчала до процедурного коду, хоча і з використанням об’єктів.
3. Інфраструктура. Попередній пункт породив іншу цікаву проблему. Люди погано знали якусь інфраструктуру. Наприклад, мучились з масивами або базою даних там, де можна було використати списки. На пропозицію скористатись списком не відразу розуміли, що мова йде не про віджет, а про структуру даних :) і т.і.
Одним словом, зовсім не дивно, що з Delphi з’їхали, в більшості своїй, на C#.
