Парадигми підходять для програмування інтерфейсу користувача

Це більш конкретний питання (або насправді два, але вони пов'язані), що випливає з коментарів загибелі технології OOP, коли хтось заявив, що OOP не є правильною парадигмою для програмування GUI.

Читаючи коментарі там і тут, я все ще відчуваю, що слід дізнатись: які парадигми програмування вважаються хорошими і чому вони кращі за інші (можливо, приклади для ілюстрації?)

Я вилучив tk-приклад із заголовка та питання

object-oriented paradigms

— Інків
джерело

@Inca - майте на увазі, що SK-логіка (яка виникла з цього коментаря) бореться з OOP при кожному можливому випадку - як якщо б у нього була фанатична місія. Я дуже сумніваюся, що він справді може довести, що tk взагалі не пов'язаний з OOP.

— Андреас Долк

-1: за цитування особистої думки, ніби це було фактом. "OOP не є правильною парадигмою для програмування GUI" буде летіти перед обличчям C # і цілі C, які, здається, дуже сильно залежать від OOP для програмування GUI. Якщо це не правильна парадигма, то вся величезна частка ринку Apple насправді не існує або щось таке.

— С.Лотт

@ S.Lott це не правильна парадигма, GUI повинен бути декларативним. Ви начебто плутаєте популярність з правильним.

— Райнос

@Raynos: "декларативний". Як у деяких пов'язаних об'єктах? Я не розумію, як декларативність - це не зв'язок між купою об'єктів. І. Це здається поза темою для цього питання. Здається, питання стосується ОО, а не кращих способів написання графічного інтерфейсу. Заголовок здається оманливим у порівнянні з фактичним питанням. Не дуже добре.

— S.Lott

@Inca: Розгляньте її ігнорування цілком як просто гіперболу.

— С.Лотт

Відповіді:

Я, як правило, не є прихильником OOP, але я б сказав, що програмування GUI дає деякі найкращі можливості використовувати сильні моменти OOP. Реалізація різних віджетів значно полегшує використання поліморфізму та успадкування ООП. Бібліотека графічного інтерфейсу PLT Racket - хороший приклад.

— Ларрі Коулман
джерело

Функціональне реактивне програмування все ж здається кращим.

— SK-логіка

@ SK-логіка: Ви могли б зробити дуже хороший випадок для цього, і якась цікава робота в Common Lisp (ви чули про Клітини?) Була зроблена в цьому напрямку. Я відредагую свою відповідь, щоб зробити її більш точною.

— Ларрі Коулман

Типовий графічний інтерфейс, який складається з віджетів та їх верстки, є повністю декларативним. Віджети самі по собі не взаємодіють один з одним, тому поняття об’єктів і повідомлень тут дещо чуже. Ієрархічні декларативні DSL - це своєрідний мейнстрім, який Tk є одним із ранніх прикладів, а WPF - більш сучасний підхід до того ж. Функціональне реактивне програмування - ще один цікавий (але не дуже поширений) підхід.

Деякі люди схильні бачити ООП де завгодно, де визначена ієрархія, що неправильно - немає абсолютно ніякого зв’язку між суворими ієрархіями (читати - алгебраїчними типами даних) та визначенням КЕП OOP.

— SK-логіка
джерело

З мого досвіду, віджети дійсно потребують взаємодії один з одним, щоб покращити графічний інтерфейс, і більше декларативних систем, з якими я стикався (певні на основі XML, включаючи HTML + css), безумовно, не мають можливостей у частині взаємодії. Крім того, мій досвід включення інтерфейсу користування декларативним (prolog) та функціональним (Haskell) насправді не створював враження, що це було легко. Чи є у вас джерела, на які я міг би поглянути на це, зокрема обговорити більше цього? Я придумав лише дуже абстрактні (або дуже основні) приклади, які не дуже пояснюють, чому певні підходи працюють краще

— Інка,