Next: Un Interface-Builder typé?
Up: Panoramique et comparaison de
Previous: Extension ``verticale'' du code
Le paradigme Target/Action
Un des slogans'' de l'orienté-objet est celui de la construction
d'applications à l'aide de composantes réutilisables dont on n'a pas forcément
le code. Cela dégénère des fois aussi en une sorte de promesse que tout ira bien
même si vous codez avant et réfléchissez après, et non le contraire, mais bon.<BR>
<P>
Un des meilleurs exemples de réalisation de ce slogan est l'<I>Inteface
Builder<A NAME="358"> </A></I> qui fait partie de l'environnement de développement de
<I>NEXTSTEP<A NAME="360"> </A></I>/<I>OPENSTEP<A NAME="362"> </A></I>, du à Jean-Marie Hullot. On peut voir
à quoi cela ressemble concrétement sur la figure <A HREF="node21.html#fIB">1.1</A>.<BR>
<P>
<P><A NAME="243"> </A> <IMG ALIGN=BOTTOM ALT="figure203" SRC="img5.gif" > <BR>
<STRONG>Figure 1.1:</STRONG> Interface Builder et le Target/Action paradigm.<A NAME="fIB"> </A><BR>
<P>
<P>
Cet outil exploite au maximum un paradigme bien précis, celui de target/action,
qui prévoit que tout objet ayant une interaction avec l'utilisateur dispose de
deux variables d'instance, <I>target<A NAME="364"> </A></I> et <I>action<A NAME="366"> </A></I>, configurables à
travers des méthodes de l'objet, qui définissent à quelle objet (le target)
envoyer quel message (l'action) en réponse à une intervention de l'utilisateur.<BR>
<P>
Si on vit dans le monde C-like, ou les fonctions sans nom et les variables
locales n'existent qu'à un seul niveau, une telle mécanique oblige à demander
que le langage fournisse:
<P>
<UL><LI> le typage dynamique: on ne sait pas a priori qui sera le target, donc on
ne peut assumer rien de mieux que le fait qu'il est un objet, dont le
type moins spécifique est <I>id<A NAME="368"> </A></I>, le type de défaut de tout objet
non autrement qualifié
<PRE>- target;
- setTarget:anObject;</PRE><LI> les méthodes comme valeurs de première classe (passable en paramètre
et calculables), dont le type est <I>SEL<A NAME="370"> </A></I>
<PRE>- (SEL)action;
- setAction:(SEL)aSelector;</PRE>
</UL>
<P>
On verra tout de suite qu'on peut conturner cela dans un langage fonctionnel
typé, tant qu'on n'a pas bésoin de passer en paramétre à l'objet target l'objet
qui declenche l'action. Mais si on veut que le target puisse intéragir avec ceux
qui lui envoient l'action, on doit considérer uneaction'' comme une méthode
avec en paramètre le id de l'objet qui déclenche l'action: cela est
nécessaire pour que les mécanismes de Interface-Builder restent simples. Or, on
ne peut pas savoir à l'avance de qui ce message viendra, et alors la déclaration
de l'action ne pourra être que
- faitqquechose: sender;dans tout objet pouvant recevoir un message qui est une action, où le type de sender , l'objet envoyant l'action, est bien, par défaut, id.
Cela se fait aussi en Delphi de Borland, où on retrouve des tests dynamiques de type tel isa.
Next: Un Interface-Builder typé? Up: Panoramique et comparaison de Previous: Extension ``verticale'' du code Roberto DiCosmo
Mon Jun 3 18:29:31 MET DST 1996