Paradigmi adatti per la programmazione dell'interfaccia utente


9

Questa è una domanda più specifica (o in realtà due, ma sono correlate) proveniente dai commenti sulla morte della tecnologia OOP in cui qualcuno ha affermato che OOP non è il paradigma giusto per la programmazione della GUI.

Leggendo i commenti lì e qui ho ancora la sensazione che ci siano cose da imparare: quali paradigmi di programmazione sono considerati adatti e perché sono migliori di altri (forse con esempi da illustrare?)

Ho rimosso l'esempio tk dal titolo e dalla domanda


@Inca - tieni presente che la logica SK (che ha originato questo commento) combatte OOP in ogni possibile occasione, come se avesse una missione fanatica. Dubito fortemente che possa davvero dimostrare che tk non è affatto correlato a OOP.
Andreas_D,

-1: per citare un'opinione personale come se fosse un fatto. "OOP non è il paradigma giusto per la programmazione della GUI" volerebbe di fronte a C # e Obiettivo C che sembrano dipendere fortemente da OOP per la programmazione della GUI. Se non è il paradigma giusto, allora l'enorme quota di mercato di Apple non esiste o qualcosa del genere.
S. Lott,

1
@ S. Lott non è però il paradigma giusto, la GUI dovrebbe essere dichiarativa. Sembra che stai confondendo la popolarità con ciò che è giusto.
Raynos,

@Raynos: "dichiarativo". Come in, alcuni oggetti correlati? Non capisco come dichiarativo non sia un mucchio di relazioni tra un mucchio di oggetti. E. Sembra fuori tema per questa domanda. La domanda sembra riguardare OO, non i modi migliori per scrivere la GUI. Il titolo sembra fuorviante rispetto alla domanda reale. Né sono molto buoni.
S.Lott

1
@Inca: considera di ignorarlo del tutto come una semplice iperbole.
S.Lott

Risposte:


9

Normalmente non sono un sostenitore di OOP, ma direi che la programmazione della GUI presenta alcune delle migliori opportunità per utilizzare i punti di forza di OOP. L'implementazione di vari widget è molto più semplice usando il polimorfismo e l'eredità di OOP. La libreria GUI di PLT Racket è un buon esempio.


2
La programmazione reattiva funzionale sembra tuttavia adattarsi meglio.
SK-logic,

@ SK-logic: potresti fare un ottimo esempio, e qualche lavoro interessante in Common Lisp (hai sentito parlare di Cells?) È stato fatto in quella direzione. Modificherò la mia risposta per renderla più precisa.
Larry Coleman,

5

Una GUI tipica, fatta di widget e il loro layout, è interamente dichiarativa. I widget di per sé non interagirebbero tra loro, quindi qui una nozione di oggetti e messaggi è alquanto aliena. I DSL dichiarativi gerarchici sono una sorta di mainstream attualmente, con Tk che è uno dei primi esempi e WPF come approccio più moderno alla stessa cosa. La programmazione reattiva funzionale è un altro approccio interessante (ma non molto diffuso).

Alcune persone tendono a vedere OOP ovunque sia definita una gerarchia, il che è sbagliato - non c'è assolutamente alcuna connessione tra gerarchie rigorose (leggi - tipi di dati algebrici) e la definizione di OOP di Kay.


3
Nella mia esperienza, i widget devono interagire tra loro per creare una GUI migliore e i sistemi più dichiarativi che ho incontrato (alcuni basati su XML, tra cui HTML + CSS) certamente mancano di possibilità nella parte di interazione. Inoltre, le mie esperienze con l'integrazione dell'interfaccia utente usando dichiarative (prolog) e funzionali (Haskell) non hanno dato l'impressione che fosse facile. Hai delle fonti che potrei esaminare per discutere in modo specifico di questo? Ho solo fornito esempi molto astratti (o molto basilari) che non spiegano molto perché alcuni approcci funzionano meglio
Inca,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.