Paradigmes adaptés à la programmation de l'interface utilisateur


9

Il s'agit d'une question plus spécifique (ou en fait deux, mais elles sont liées) provenant des commentaires de la mort de la technologie OOP où quelqu'un a déclaré que la POO n'est pas le bon paradigme pour la programmation GUI.

En lisant les commentaires ici et ici, j'ai toujours le sentiment qu'il y a des choses à apprendre: quels paradigmes de programmation sont considérés comme de bons ajustements et pourquoi sont-ils meilleurs que d'autres (peut-être avec des exemples pour illustrer?)

J'ai supprimé l'exemple tk du titre et de la question


@Inca - gardez à l'esprit que SK-logic (à l'origine de ce commentaire) combat la POO à chaque occasion possible - comme s'il avait une mission fanatique. Je doute fortement qu'il puisse vraiment prouver que tk n'est pas du tout lié à la POO.
Andreas_D

-1: pour avoir cité une opinion personnelle comme si c'était un fait. "La POO n'est pas le bon paradigme pour la programmation GUI" irait à l'encontre de C # et de l'Objectif C qui semblent dépendre très fortement de la POO pour la programmation GUI. Si ce n'est pas le bon paradigme, alors l'énorme part de marché d'Apple n'existe pas vraiment ou quelque chose comme ça.
S.Lott

1
@ S.Lott, ce n'est pas le bon paradigme, l'interface graphique doit être déclarative. Vous semblez confondre la popularité avec ce qui est juste.
Raynos

@Raynos: "déclaratif". Comme dans, certains objets liés? Je ne comprends pas à quel point déclarative n'est pas un tas de relations entre un tas d'objets. Et. Cela semble hors sujet pour cette question. La question semble concerner OO, pas de meilleures façons d'écrire des GUI. Le titre semble trompeur par rapport à la question réelle. Ni l'un ni l'autre ne sont très bons.
S.Lott

1
@Inca: envisagez de ne pas le considérer comme une simple hyperbole.
S.Lott

Réponses:


9

Je ne suis pas normalement un partisan de la POO, mais je dirais que la programmation GUI présente certaines des meilleures opportunités pour utiliser les points forts de la POO. L'implémentation de divers widgets est rendue beaucoup plus facile en utilisant le polymorphisme et l'héritage d'OOP. La bibliothèque GUI de PLT Racket est un bon exemple.


2
La programmation réactive fonctionnelle semble pourtant mieux adaptée.
SK-logic

@ SK-logic: Vous pourriez faire un très bon argument pour cela, et un travail intéressant en Common Lisp (avez-vous entendu parler de Cells?) A été fait dans ce sens. Je vais modifier ma réponse pour la rendre plus précise.
Larry Coleman

5

Une interface graphique typique, composée de widgets et de leur disposition, est entièrement déclarative. Les widgets en soi n'interagiraient pas entre eux, donc une notion d'objets et de messages est quelque peu étrangère ici. Les DSL déclaratives hiérarchiques sont actuellement une sorte de courant dominant, Tk étant l'un des premiers exemples, et WPF comme approche plus moderne de la même chose. La programmation réactive fonctionnelle est une autre approche intéressante (mais peu répandue).

Certaines personnes ont tendance à voir la POO partout où une hiérarchie est définie, ce qui est faux - il n'y a absolument aucun lien entre des hiérarchies strictes (lecture - types de données algébriques) et la définition de Kay de la POO.


3
D'après mon expérience, les widgets doivent interagir les uns avec les autres pour faire une meilleure interface graphique, et les systèmes plus déclaratifs que j'ai rencontrés (certains basés sur xml, y compris HTML + css) manquent certainement de possibilités dans la partie interaction. De plus, mes expériences avec l'incorporation de l'interface utilisateur en utilisant déclarative (prologue) et fonctionnelle (Haskell) n'ont pas vraiment donné l'impression que c'était facile. Avez-vous des sources que je pourrais consulter pour en discuter plus spécifiquement? Je n'ai trouvé que des exemples très abstraits (ou très basiques) qui n'expliquent pas vraiment pourquoi certaines approches fonctionnent mieux
Inca
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.