Cours complet Pharo par l'exemple

Les variables d’instance en Smalltalk sont privées vis-à-vis de l’instance elle-même. Ceci diffère de langages comme Java et C++ qui permettent l’accès aux variables d’instance (aussi connues sous le nom d’« attributs » ou « variables membre ») depuis n’importe qu’elle autre instance de la même classe. Nous disons que la frontière d’encapsulation(33) des objets en Java et en C++ est la classe, là où, en Smalltalk, c’est l’instance.

En Smalltalk, deux instances d’une même classe ne peuvent pas accéder aux variables d’instance l’une de l’autre à moins que la classe ne définisse des « méthodes d’accès » (en anglais, accessor methods). Aucun élément de la syntaxe ne permet l’accès direct à la variable d’instances de n’importe quel autre objet. (En fait, un mécanisme appelé réflexivité offre une possibilité d’interroger un autre objet sur la valeur de ses variables d’instance ; ces facilités de métaprogrammation permettent d’écrire des outils tels que l’inspecteur d’objets (nous utiliserons aussi le terme Inspector). La seule vocation de ce dernier est de regarder le contenu des autres objets.)

Les variables d’instance peuvent être accédées par nom dans toutes les méthodes d’instance de la classe qui les définit ainsi que dans les méthodes définies dans les sous-classes de cette classe. Cela signifie que les variables d’instance en Smalltalk sont semblables aux variables protégées (protected) en C++ et en Java. Cependant, nous préférons dire qu’elles sont privées parce qu’il n’est pas d’usage en Smalltalk d’accéder à une variable d’instance directement depuis une sous-classe.

Exemple

La méthode Point»dist: (méthode 5.1) calcule la distance entre le receveur et un autre point. Les variables d’instance x et y du receveur sont accédées directement par le corps de la méthode. Cependant, les variables d’instance de l’autre point doivent être accédées en lui envoyant les messages x et y.

Point»dist: aPoint
  "Retour ne la distance entre aPoint et le receveur."
  | dx dy |
  dx := aPoint x - x.
  dy := aPoint y - y.
  ↑ ((dx * dx) + (dy * dy)) sqrt
  1@1 dist: 4@5 −→ 5.0

La raison-clef de préférer l’encapsulation basée sur l’instance à l’encapsulation basée sur la classe tient au fait qu’elle permet à différentes implémentations d’une même abstraction de coexister. Par exemple, la méthode point» dist: n’a besoin ni de surveiller, ni même de savoir si l’argument aPoint est une instance de la même classe que le receveur. L’argument objet pourrait être représenté par des coordonnées polaires, voire comme un enregistrement dans une base de données ou sur une autre machine d’un réseau distribué ; tant qu’il peut répondre aux messages x et y, le code de la méthode 5.1 fonctionnera toujours.

Toutes les méthodes sont publiques(34). Les méthodes sont regroupées en protocoles qui indiquent leur objectif. Certains noms de protocoles courants ont été attribués par convention, par exemple, accessing pour les méthodes d’accès, et initialization pour construire un état initial stable pour l’objet. Le protocole private est parfois utilisé pour réunir les méthodes qui ne devraient pas être visibles depuis l’extérieur. Rien ne vous empêche cependant d’envoyer un message qui est implémenté par une telle méthode « privée ».

Les méthodes peuvent accéder à toutes les variables d’instance de l’objet. Certains programmeurs en Smalltalk préfèrent accéder aux variables d’instance uniquement au travers des méthodes d’accès. Cette pratique a un certain avantage, mais elle tend à rendre l’interface de vos classes chaotique, ou pire, à exposer des états privés à tous les regards.

Puisque les classes sont des objets, elles peuvent avoir leurs propres variables d’instance ainsi que leurs propres méthodes. Nous les appelons variables d’instance de classe (en anglais class instance variables) et méthodes de classe, mais elles ne sont véritablement pas différentes des variables et méthodes d’instances ordinaires : les variables d’instance de classe ne sont seulement que des variables d’instance définies par une métaclasse. Quant aux méthodes de classe, elles correspondent juste aux méthodes définies par une métaclasse.

Une classe et sa métaclasse sont deux classes distinctes, et ce, même si cette première est une instance de l’autre. Pour vous, tout ceci sera somme toute largement trivial : vous n’aurez qu’à vous concentrer sur la définition du comportement de vos objets et des classes qui les créent.

De ce fait, le navigateur de classes nommé Browser vous aide à parcourir à la fois classes et métaclasses comme si elles n’étaient qu’une seule entité avec deux « côtés » : le « côté instance » et le « côté classe », comme le montre la figure 5.1. En cliquant sur le bouton instance , vous voyez la présentation de la classe Color et vous donc pouvez naviguer dans les méthodes qui sont exécutées quand les messages de même nom sont envoyés à une instance de Color, comme blue (correspondant à la couleur bleue). En appuyant sur le bouton class (pour classe), vous naviguez dans la classe Color class, autrement dit vous voyez les méthodes qui seront exécutées en envoyant les messages directement à la classe Color elle-même. Par exemple, Color blue envoie le message blue (pour bleu) à la classe Color. Vous trouverez donc la méthode blue définie côté classe de la classe Color et non du côté instance.

aColor := Color blue.   "Méthode de classe blue"
aColor      −→ Color blue
aColor red  −→ 0.0      "Méthode d'accès red (rouge) côté instance"
aColor blue −→ 1.0      "Méthode d'accès blue (bleu) côté instance"

Vous définissez une classe en remplissant le patron (ou template en anglais) proposé dans le côté instance. Quand vous acceptez ce patron, le système crée non seulement la classe que vous définissez, mais aussi la métaclasse correspondante. Vous pouvez naviguer dans la métaclasse en cliquant sur le bouton class. Du patron employé pour la création de la métaclasse, seule la liste des noms des variables d’instance vous est proposée pour une édition directe.

Une fois que vous avez créé une classe, cliquer sur le bouton instance vous permet d’éditer et de parcourir les méthodes qui seront possédées par les instances de cette classe (et de ses sous-classes). Par exemple, nous pouvons voir dans la figure 5.1 que la méthode hue est définie pour les instances de la classe Color. A contrario, le bouton class vous laisse parcourir et éditer la métaclasse (dans ce cas Color class).

Les méthodes de classe peuvent être relativement utiles ; naviguez dans Color class pour voir quelques bons exemples. Vous verrez qu’il y a deux sortes de méthodes définies dans une classe : celles qui créent les instances de la classe, comme Color class»blue et celles qui ont une action utilitaire, comme Color class»showColorCube. Ceci est courant, bien que vous trouverez occasionnellement des méthodes de classe utilisées d’une autre manière.

Il est commun de placer des méthodes utilitaires dans le côté classe parce qu’elles peuvent être exécutées sans avoir à créer un objet additionnel dans un premier temps. En fait, beaucoup d’entre elles contiennent un commentaire pour les rendre plus compréhensibles pour l’utilisateur qui les exécute.

Vous verrez l’effet de l’exécution de cette méthode. (Sélectionnez World ▷ restore display (r) pour annuler les effets.)

Pour les familiers de Java et C++, les méthodes de classe peuvent être assimilées aux méthodes statiques. Néanmoins, l’homogénéité de Smalltalk induit une différence : les méthodes statiques de Java sont des fonctions résolues de manière statique alors que les méthodes de classe de Smalltalk sont des méthodes à transfert dynamique(35). Ainsi, l’héritage, la surcharge et l’utilisation de super fonctionnent avec les méthodes de classe dans Smalltalk, ce qui n’est pas le cas avec les méthodes statiques en Java.

Dans le cadre des variables d'instance ordinaires, toutes les instances d’une classe partagent le même ensemble de noms de variables et les instances de ses sous-classes héritent de ces noms ; cependant, chaque instance possède son propre jeu de valeurs. C’est exactement la même histoire avec les variables d’instance de classe : chaque classe a ses propres variables d’instance de classe privées. Une sous-classe héritera de ces variables d’instance de classe, mais elle aura ses propres copies privées de ces variables. Aussi vrai que les objets ne partagent pas les variables d’instance, les classes et leurs sous-classes ne partagent pas les variables d’instance de classe.

Vous pouvez utiliser une variable d’instance de classe count(36) afin de suivre le nombre d’instances que vous créez pour une classe donnée. Cependant, les sous-classes ont leur propre variable count, les instances des sous-classes seront comptées séparément.

Exemple : les variables d’instance de classe ne sont pas partagées avec les sous-classes. Soit les classes Dog et Hyena(37) telles que Hyena hérite de la variable d’instance de classe count de la classe Dog.

Object subclass: #Dog
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''
  category: 'PBE-CIV'

Dog class
  instanceVariableNames: 'count'

Dog subclass: #Hyena
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''
  category: 'PBE-CIV'

Supposons que nous ayons des méthodes de classe de Dog pour initialiser sa variable count à 0 et pour incrémenter cette dernière quand de nouvelles instances sont créées :

Dog class»initialize
  super initialize.
  count := 0.

Dog class»new
  count := count +1.
  ↑ super new

Dog class»count
  ↑ count

Maintenant, à chaque fois que nous créons un nouveau Dog, son compteur count est incrémenté. Il en est de même pour toute nouvelle instance de Hyena, mais elles sont comptées séparément :

Dog initialize.
Hyena initialize.
Dog count   −→ 0
Hyena count −→ 0
Dog new.
Dog count   −→ 1
Dog new.
Dog count   −→ 2
Hyena new.
Hyena count −→ 1

Remarquons aussi que les variables d’instance de classe sont privées à la classe tout comme les variables d’instance sont privées à l’instance. Comme les classes et leurs instances sont des objets différents, il en résulte que :

Une classe n’a pas accès aux variables d’instance de ses propres instances.

Une instance d’une classe n’a pas accès aux variables d’instance de classe de sa classe.

C’est pour cette raison que les méthodes d’initialisation d’instance doivent toujours être définies dans le côté instance — le côté classe n’ayant pas accès aux variables d’instance, il ne pourrait y avoir initialisation ! Tout ce que peut faire la classe, c’est d’envoyer des messages d’initialisation à des instances nouvellement créées ; ces messages pouvant bien sûr utiliser les méthodes d’accès.

De même, les instances ne peuvent accéder aux variables d’instance de classe que de manière indirecte en envoyant les messages d’accès à leur classe.

Java n’a rien d’équivalent aux variables d’instance de classe. Les variables statiques en Java et en C++ ont plutôt des similitudes avec les variables de classe de Smalltalk dont nous parlerons dans la section 5.7 : toutes les sous-classes et leurs instances partagent la même variable statique.

Exemple : Définir un Singleton. Le patron de conception(38) nommé Singleton(39) offre un exemple type de l’usage de variables d’instance de classe et de méthodes de classe. Imaginez que nous souhaitions d’une part, créer une classe WebServer et d’autre part, s’assurer qu’il n’a qu’une et une seule instance en faisant appel au patron Singleton. En cliquant sur le bouton instance dans le navigateur de classe, nous définissons la classe WebServer comme suit (classe 5.4).

Object subclass: #WebServer
  instanceVariableNames: 'sessions'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Web'

Ensuite, en cliquant sur le bouton class, nous pouvons ajouter une variable d’instance uniqueInstance au côté classe.

WebServer class
instanceVariableNames: 'uniqueInstance'

Par conséquent, la classe WebServer a désormais une autre variable d’instance, en plus des variables héritées telles que superclass et methodDict.

Nous pouvons maintenant définir une méthode de classe que nous appellerons uniqueInstance comme dans la méthode 5.6. Pour commencer, cette méthode vérifie si uniqueInstance a été initialisée ou non : dans ce dernier cas, la méthode crée une instance et l’assigne à la variable d’instance de classe uniqueInstance. In fine, la valeur de uniqueInstance est renvoyée. Puisque uniqueInstance est une variable d’instance de classe, cette méthode peut directement y accéder.

WebServer class»uniqueInstance
  uniqueInstance ifNil: [uniqueInstance := self new].
  ↑ uniqueInstance

La première fois que l’expression WebServer uniqueInstance est exécutée, une instance de la classe WebServer sera créée et affectée à la variable uniqueInstance. La seconde fois, l’instance précédemment créée sera renvoyée au lieu d’y avoir une nouvelle création.

Remarquons que la clause conditionnelle à l’intérieur du code de création de la méthode 5.6 est écrite self new et non WebServer new. Quelle en est la différence ? Comme la méthode uniqueInstance est définie dans WebServer class, vous pouvez penser qu’elles sont identiques. En fait, tant que personne ne crée une sous-classe de WebServer, elles sont pareilles. Mais en supposant que ReliableWebServer est une sous-classe de WebServer et qu’elle hérite de la méthode uniqueInstance, nous devrions nous attendre à ce que ReliableWebServer uniqueInstance réponde un ReliableWebServer. L’utilisation de self assure que cela arrivera, car il sera lié à la classe correspondante. Du reste, notez que WebServer et ReliableWebServer ont chacune leur propre variable d’instance de classe nommée uniqueInstance.

Ces deux variables ont, bien entendu, différentes valeurs.

Une classe abstraite est une classe qui n’existe que pour être héritée, au lieu d’être instanciée. Une classe abstraite est habituellement incomplète, dans le sens qu’elle ne définit pas toutes les méthodes qu’elle utilise. Les méthodes « manquantes » — celle que les autres méthodes envoient, mais qui ne sont pas définies elles-mêmes — sont dites méthodes abstraites.

Smalltalk n’a pas de syntaxe dédiée pour dire qu’une méthode ou classe est abstraite. Par convention, le corps d’une méthode abstraite contient l’expression self subclassResponsibility(41). Ceci est connu sous le nom de « marker method » ou marqueur de méthode ; il indique que les sous-classes ont la responsabilité de définir une version concrète de la méthode. Les méthodes self subclassResponsibility devraient toujours être surchargées, et ainsi, ne devraient jamais être exécutées. Si vous oubliez d’en surcharger une et que celle-ci est exécutée, une exception sera levée.

Une classe est considérée comme abstraite si l’une de ses méthodes est abstraite. Rien ne vous empêche de créer une instance d’une classe abstraite ; tout fonctionnera jusqu’à ce qu’une méthode abstraite soit invoquée.

Exemple : la classe Magnitude.

Magnitude est une classe abstraite qui nous aide à définir des objets pouvant être comparables les uns avec les autres. Les sous-classes de Magnitude devraient implémenter les méthodes <, = et hash(42). Grâce à ces messages, Magnitude définit d’autres méthodes telles que >, >=, <=, max:, min:, between:and: et d’autres encore pour comparer des objets. Ces méthodes sont héritées par les sous-classes. La méthode < est abstraite et elle est définie comme dans la méthode 5.7.

Magnitude»< aMagnitude
  "Answer whether the receiver is less than the argument."
  ↑ self subclassResponsibility

A contrario, la méthode >= est concrète ; elle est définie en fonction de < :

>= aMagnitude
  "Answer whether the receiver is greater than or equal to the argument."
  ↑ (self < aMagnitude) not

Il en va de même d’autres méthodes de comparaison.

Character est une sous-classe de Magnitude; elle surcharge la méthode subclassResponsibility de < avec sa propre version de < (voir méthode 5.9). Character définit aussi les méthodes = et hash; elles héritent entre autres des méthodes >=, <= et ∼= de la classe Magnitude.

Character»< aCharacter
  "Answer tr ue if the receiver's value < aCharacter's value."
  ↑ self asciiValue < aCharacter asciiValue

Un trait est une collection de méthodes qui peut être incluse dans le comportement d’une classe sans nécessiter un héritage. Les classes disposent non seulement d’une seule super-classe, mais aussi de la facilité offerte par le partage de méthodes utiles avec d’autres méthodes sans lien de parenté avec l’héritage.

Définir un nouveau trait se fait en remplaçant simplement le patron pour la création de la sous-classe par un message à la classe Trait.

Trait named: #TAuthor
  uses: { }
  categor y: 'PBE-LightsOut'

Nous définissons ici le trait TAuthor dans la catégorie PBE-LightsOut. Ce trait n’utilise(43) aucun autre trait existant. En général, nous pouvons spécifier l’expression de composition d’un trait par d’autres traits en utilisant le mot-clef uses:. Dans notre cas, nous écrivons un tableau vide ({ }).

Les traits peuvent contenir des méthodes, mais aucune variable d’instance. Supposons que nous voulons ajouter une méthode author (auteur en anglais) à différentes classes sans lien hiérarchique ; nous le ferions ainsi :

TAuthor»author
  "Returns author initials"
  ↑ 'on' "oscar nierstrasz"

Maintenant, nous pouvons employer ce trait dans une classe ayant déjà sa propre super-classe, disons, la classe LOGame que nous avons définie dans le chapitre 2. Nous n’avons qu’à modifier le patron de création de la classe LOGame pour y inclure cette fois l’argument clef uses: suivi du trait à utiliser : TAuthor.

BorderedMorph subclass: #LOGame
  uses: TAuthor
  instanceVariableNames: 'cells'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'PBE-LightsOut'

Si nous instancions maintenant LOGame, l’instance répondra comme prévu au message author.

LOGame new author −→ 'on'

Les expressions de composition de trait peuvent combiner plusieurs traits grâce à l’opérateur +. En cas de conflit (c.-à-d.. quand plusieurs traits définissent des méthodes avec le même nom), ces conflits peuvent être résolus en retirant explicitement ces méthodes (avec -) ou en redéfinissant ces méthodes dans la classe ou le trait que vous êtes en train de définir. Il est possible aussi de créer un alias des méthodes (avec @) leur fournissant ainsi un nouveau nom.

Les traits sont employés dans le noyau du système(44). Un bon exemple est la classe Behavior.

Object subclass: #Behavior
  uses: TPureBehavior @ {#basicAddTraitSelector:withMethod:->
    #addTraitSelector:withMethod:}
  instanceVariableNames: 'superclass methodDict format'
  classVariableNames: 'ObsoleteSubclasses'
  poolDictionaries: ''
  category: 'Kernel-Classes'

Ici, nous voyons que la méthode basicAddTraitSelector:withMethod: définie dans le trait TPureBehavior a été renommée en addTraitSelector:withMethod:. Les traits sont à présent supportés par les navigateurs de classe (ou browsers).

Supposons la création d’une instance de EllipseMorph.

anEllipse := EllipseMorph new.

Si nous envoyons à cet objet le message defaultColor, nous obtenons le résultat Color yellow(45) :

anEllipse defaultColor −→ Color yellow

La classe EllipseMorph implémente defaultColor, donc la méthode adéquate est trouvée immédiatement.

EllipseMorph»defaultColor
  "answer the default color/fill style for the receiver"
  ↑ Color yellow

A contrario, si nous envoyons le message openInWorld à anEllipse, la méthode n’est pas trouvée immédiatement parce que la classe EllipseMorph n’implémente pas openInWorld. La recherche continue plus avant dans la super-classe BorderedMorph, puis, ainsi de suite, jusqu’à ce qu’une méthode openInWorld soit trouvée dans la classe Morph (voir la figure 5.2).

Morph»openInWorld
  "Add this mor ph to the wor ld."

self openInWorld: self currentWorld

Remarquez que EllipseMorph»defaultColor (méthode 5.14) renvoie explicitement Color yellow alors que Morph»openInWorld (méthode 5.15) semble ne rien retourner.

En réalité, une méthode renvoie toujours une valeur qui est, bien entendu, un objet. La réponse peut être explicitement définie par l’utilisation du symbole ↑ dans la méthode. Si lors de l’exécution, on atteint la fin de la méthode sans avoir rencontré de ↑, la méthode retournera toujours une valeur : l’objet receveur lui-même. On dit habituellement que la méthode « renvoie self », parce qu’en Smalltalk la pseudovariable self représente le receveur du message. En Java, on utilise le mot-clef this.

Ceci induit le constat suivant : la méthode 5.15 est équivalente à la méthode 5.16 :

Morph»openInWorld
  "Add this mor ph to the wor ld."

self openInWorld: self currentWorld.
 ↑ self "Don't do this unless you mean it"

Pourquoi écrire ↑ self explicitement n’est pas une bonne chose à faire ? Parce que, quand vous renvoyez explicitement quelque chose, vous communiquez que vous retournez quelque chose d’importance à l’expéditeur du message. Dès lors vous spécifiez que vous attendez que l’expéditeur fasse quelque chose de la valeur retournée. Puisque ce n’est pas le cas ici, il est préférable de ne pas renvoyer explicitement self.

C’est une convention en Smalltalk, ainsi résumée par Kent Beck se référant à la valeur de retour importante « Interesting return value »(46) :

Renvoyez une valeur seulement quand votre objet expéditeur en a l’usage †.
†. Return a value only when you intend for the sender to use the value.

Si nous revenons à la hiérarchie de classe EllipseMorph dans la figure 5.2, nous voyons que les classes Morph et EllipseMorph implémentent toutes deux defaultColor. En fait, si nous ouvrons un nouvel élément graphique Morph (Morph new openInWorld), nous constatons que nous obtenons un morph bleu, là où l’ellipse (EllipseMorph) est jaune (yellow) par défaut.

Nous disons que EllipseMorph surcharge la méthode defaultColor qui hérite de Morph. La méthode héritée n’existe plus du point de vue d’anEllipse.

Parfois nous ne voulons pas surcharger les méthodes héritées, mais plutôt les étendre avec de nouvelles fonctionnalités; autrement dit, nous souhaiterions pouvoir invoquer la méthode surchargée complétée par la nouvelle fonctionnalité que nous aurons définie dans la sous-classe. En Smalltalk, comme dans beaucoup de langages orientés objet reposant sur l’héritage simple, nous pouvons le faire à l’aide d’un envoi de message à super.

La méthode initialize est l’exemple le plus important de l’application de ce mécanisme. Quand une nouvelle instance d’une classe est initialisée, il est vital d’initialiser toutes les variables d’instance héritées. Cependant, les méthodes initialize de chacune des super-classes de la chaîne d’héritage fournissent déjà la connaissance nécessaire. La sous-classe n’a pas à s’occuper d’initialiser les variables d’instance héritées !

Envoyer super initialize avant toute autre considération lors de la création d’une méthode d’initialisation est une bonne pratique :

BorderedMorph»initialize
  "initialize the state of the receiver"
  super initialize.
  self borderInitialize

Une méthode initialize devrait toujours commencer par la ligne super initialize.

Nous avons besoin des envois sur super pour réutiliser le comportement hérité qui pourrait sinon être surchargé. Cependant, la technique habituelle de composition de méthodes, héritées ou non, est basée sur l’envoi à self.

Comment l’envoi à self diffère-t-il de celui à super ? Comme self, super représente le receveur du message. La seule différence est dans la méthode de recherche. Au lieu de faire partir la recherche depuis la classe du receveur, celle-ci démarre dans la super-classe de la méthode dans laquelle l’envoi à super se produit.

Remarquez que super n’est pas la super-classe ! C’est une erreur courante et normale que de le penser. C’est aussi une erreur de penser que la recherche commence dans la super-classe du receveur. Nous allons voir précisément comment cela marche avec l’exemple suivant.

Considérons le message constructorString, que nous pouvons envoyer à n’importe quel morph :

anEllipse constructorString −→ '(EllipseMorph newBounds: (0@0 corner: 50@40)
    color: Color yellow)'

La valeur de retour est une chaîne de caractères qui peut être évaluée pour recréer un morph.

Comment ce résultat est-il exactement obtenu grâce à l’association de self et de super ? Pour commencer, anEllipse constructorString trouvera la méthode constructorString dans la classe Morph, comme vu dans la figure 5.3.

Morph»constructorString
↑ String streamContents: [:s | self printConstructorOn: s indent: 0]

La méthode Morph»constructorString envoie le message printConstructorOn:indent: à self. La méthode correspondant à ce message est alors recherchée dans la hiérarchie de classes d’abord en en commençant dans la classe EllipseMorph et finalement trouvée dans Morph. Cette méthode en retour envoie à self le message printConstructorOn:indent:nodeDict:, qui, à son tour, envoie fullPrintOn: à self. Encore une fois, fullPrintOn: est recherché depuis la classe EllipseMorph et fullPrintOn: est trouvé dans BorderedMorph (revoir la figure 5.3). Ce qui est crucial à observer est le fait qu’un envoi à self provoque une recherche de méthode qui débute dans la classe du receveur, à savoir la classe de anEllipse.

Un envoi à self déclenche le départ de la recherche dynamique de méthode dans la classe du receveur.

BorderedMorph»fullPrintOn: aStream
  aStream nextPutAll: '('.
  super fullPrintOn: aStream.
  aStream nextPutAll: ') setBorderWidth: '; print: borderWidth;
  nextPutAll: ' borderColor: ' , (self colorString: borderColor)

Maintenant, BorderedMorph»fullPrintOn: utilise l’envoi à super pour étendre le comportement fullPrintOn: hérité de sa super-classe. Parce qu’il s’agit d’un envoi à super, la recherche démarre alors depuis la super-classe de la classe dans laquelle se produit l’envoi à super, autrement dit, dans Morph. Nous trouvons ainsi immédiatement Morph»fullPrintOn: que nous évaluons.

Notez que la recherche sur super n’a pas commencé dans la super-classe du receveur. Ainsi il en aurait résulté un départ de la recherche depuis BorderedMorph, créant alors une boucle infinie !

Un envoi à super déclenche un départ de recherche statique de méthode dans la super-classe de la classe dont la méthode envoie le message à super.

Si vous regardez attentivement l’envoi à super et la figure 5.3, vous réaliserez que les liens avec super sont statiques : tout ce qui importe est la classe dans laquelle le texte de l’envoi à super est trouvé. A contrario, le sens de self est dynamique : self représente toujours le receveur du message courant exécuté. Ce qui signifie que tout message envoyé à self est recherché en partant de la classe du receveur.

Que se passe-t-il si la méthode que nous cherchons n’est pas trouvée ?

Supposons que nous envoyons le message foo à une ellipse anEllipse. Tout d’abord, la recherche normale de cette méthode aurait à parcourir toute la chaîne d’héritage jusqu’à la classe Object (ou plutôt ProtoObject). Comme cette méthode n’est pas trouvée, la machine virtuelle veillera à ce que l’objet envoie self doesNotUnderstand: #foo. (voir la figure 5.4.)

Ceci est un envoi dynamique de message tout à fait normal. Ainsi, la recherche recommence depuis la classe EllipseMorph, mais cette fois-ci en cherchant la méthode doesNotUnderstand:(47). Il apparaît que Object implémente doesNotUnderstand:. Cette méthode créera un nouvel objet MessageNotUnderstood (en français : message incompréhensible) capable de démarrer Debugger, le débogueur, dans le contexte actuel de l’exécution.

Pourquoi prenons-nous ce chemin sinueux pour gérer une erreur si évidente ? Parce qu’en faisant ainsi, le développeur dispose de tous les outils pour agir alternativement grâce à l’interception de ces erreurs. N’importe qui peut surcharger la méthode doesNotUnderstand: dans une sous-classe de Object en étendant ses possibilités en offrant une façon différente de capturer l’erreur.

En fait, nous nous simplifions la vie en implémentant une délégation automatique de messages d’un objet à un autre. Un objet Delegator peut simplement déléguer tous les messages qu’il ne comprend pas à un autre objet dont la responsabilité est de les gérer ou de lever une erreur lui-même !

En Pharo, toutes les variables globales sont stockées dans un espace de nommage appelé Smalltalk qui est une instance de la classe SystemDictionary. Les variables globales sont accessibles de partout. Toute classe est nommée par une variable globale ; en plus, quelques variables globales sont utilisées pour nommer des objets spéciaux ou couramment utilisés.

La variable Transcript nomme une instance de TranscriptStream, un flux de données ou stream qui écrit dans une fenêtre à ascenseur (dite aussi scrollable). Le code suivant affiche des informations dans le Transcript en passant une ligne.

Transcript show: 'Pharo est extra' ; cr

Avant de lancer la commande do it, ouvrez un Transcript en sélectionnant World ▷ Tools… ▷ Transcript.

D’autres variables globales utiles

• Smalltalk est une instance de SystemDictionary (Dictionnaire Système) définissant toutes les variables globales — dont l’objet Smalltalk lui-même. Les clefs de ce dictionnaire sont des symboles nommant les objets globaux dans le code Smalltalk. Par exemple,

   

  Sélectionnez

  Smalltalk at: #Boolean −→ Boolean

  Puisque Smalltalk est lui-même aussi une variable globale,

   

  Sélectionnez

  Smalltalk at: #Smalltalk −→ a SystemDictionary(lots of globals)}

  et

   

  Sélectionnez

  (Smalltalk at: #Smalltalk) == Smalltalk −→ true

• Sensor est une instance de EventSensor. Il représente les entrées interactives ou interfaces de saisie (en anglais, input) dans Pharo. Par exemple, Sensor keyboard retourne le caractère suivant saisi au clavier, et Sensor leftShiftDown répond true (vrai en booléen) si la touche shift gauche est maintenue enfoncée, alors que Sensor mousePoint renvoie un Point indiquant la position actuelle de la souris.

• World (Monde en anglais) est une instance de PasteUpMorph représentant l’écran. World bounds retourne un rectangle définissant l’espace tout entier de l’écran; tous les morphs (objet Morph) sur l’écran sont des sousmorphs ou submorphs de World.

• ActiveHand est l’instance courante de HandMorph, la représentation graphique du curseur. Les sous-morphs de ActiveHand tiennent tout ce qui est glissé par la souris.

• Undeclared(48) est un autre dictionnaire, il contient toutes les variables non déclarées. Si vous écrivez une méthode qui référence une variable non déclarée, le navigateur de classe (Browser) vous l’annoncera normalement pour que vous la déclariez, par exemple, en tant que variable globale ou variable d’instance de la classe. Cependant, si par la suite vous effacez la déclaration, le code référencera une variable non déclarée. Inspecter Undeclared peut parfois expliquer des comportements bizarres !

• SystemOrganization est une instance de SystemOrganizer : il enregistre l’organisation des classes en paquets. Plus précisément, il catégorise les noms des classes ainsi :

SystemOrganization categoryOfElement: #Magnitude −→ #'Kernel-Numbers'

Une pratique courante est de limiter fortement l’usage des variables globales ; il est toujours préférable d’utiliser des variables d’instance de classes ou des variables de classes et de fournir des méthodes de classe pour y accéder. En effet, si aujourd’hui Pharo devait être reprogrammé à partir de zéro(49) 19, la plupart des variables globales qui ne sont pas des classes seraient remplacées par des Singletons.

La technique habituellement employée pour définir une variable globale est simplement de faire un do it sur une affectation d’un identifiant non déclaré commençant par une majuscule. Dès lors, l’analyseur syntaxique ou parser vous la déclarera en tant que variable globale. Si vous voulez en définir une de manière programmatique, exécutez Smalltalk at: #AGlobalName put: nil.

Pour l’effacer, exécutez Smalltalk removeKey: #AGlobalName.

Nous avons besoin parfois de partager des données entre les instances d’une classe et la classe elle-même. C’est possible grâce aux variables de classe. Le terme variable de classe indique que le cycle de vie de la variable est le même que celui de la classe. Cependant, le terme ne véhicule pas l’idée que ces variables sont partagées aussi bien parmi toutes les instances d’une classe que dans la classe elle-même comme nous pouvons le voir sur la figure 5.5. En fait, variables partagées (ou shared variables, en anglais) aurait été un meilleur nom, car ce dernier exprime plus clairement leur rôle tout en pointant le danger de les utiliser, en particulier si elles sont sujettes aux modifications.

Sur la figure 5.5, nous voyons que rgb et cachedDepth sont des variables d’instance de Color uniquement accessibles par les instances de Color. Nous remarquons aussi que superclass, subclass, methodDict… etc., sont des variables d’instance de classe, c.-à-d. des variables d’instance accessibles seulement par Color class.

Mais nous pouvons noter quelque chose de nouveau : ColorNames et CachedColormaps sont des variables de classe définies pour Color. La capitalisation du nom de ces variables nous donne un indice sur le fait qu’elles sont partagées. En fait, non seulement toutes les instances de Color peuvent accéder à ces variables partagées, mais aussi la classe Color elle-même, ainsi que toutes ses sous-classes. Les méthodes d’instance et de classe peuvent accéder toutes les deux à ces variables partagées.

Une variable de classe est déclarée dans le patron de définition de la classe. Par exemple, la classe Color définit un grand nombre de variables de classe pour accélérer la création des couleurs ; sa définition est visible ci-dessous (classe 5.20).

Object subclass: #Color
    instanceVariableNames: 'rgb cachedDepth cachedBitPattern'
    classVariableNames: 'Black Blue BlueShift Brown CachedColormaps ColorChart
    ColorNames ComponentMask ComponentMax Cyan DarkGray Gray
    GrayToIndexMap Green GreenShift HalfComponentMask HighLightBitmaps
    IndexedColors LightBlue LightBrown LightCyan LightGray LightGreen LightMagenta
    LightOrange LightRed LightYellow Magenta MaskingMap Orange PaleBlue
    PaleBuff PaleGreen PaleMagenta PaleOrange PalePeach PaleRed PaleTan
    PaleYellow PureBlue PureCyan PureGreen PureMagenta PureRed PureYellow
    RandomStream Red RedShift TranslucentPatterns Transparent VeryDarkGray
    VeryLightGray VeryPaleRed VeryVeryDarkGray VeryVeryLightGray White Yellow'
    poolDictionaries: ''
    category: 'Graphics-Primitives'

La variable de classe ColorNames est un tableau contenant le nom des couleurs fréquemment utilisées. Ce tableau est partagé par toutes les instances de Color et de sa sous-classe TranslucentColor. Elles sont accessibles via les méthodes d’instance et de classe.

ColorNames est initialisée une fois dans Color class»initializeNames, mais elle est en libre accès depuis les instances de Color. La méthode Color»name utilise la variable pour trouver le nom de la couleur. Il semble en effet inopportun d’ajouter une variable d’instance name à chaque couleur, car la plupart des couleurs n’ont pas de noms.

L’initialisation de classe

La présence de variables de classe soulève une question : comment les initialiser ?

Une solution est l’initialisation dite paresseuse (ou lazy initialization en anglais). Cela est possible avec l’introduction d’une méthode d’accès qui initialise la variable, durant l’exécution, si celle-ci n’a pas été encore initialisée. Ceci nous oblige à utiliser la méthode d’accès tout le temps et à ne jamais faire appel à la variable de classe directement. De plus, notons que le coût de l’envoi d’un accesseur et le test d’initialisation sont à prendre en compte. Ceci va à l’encontre de notre motivation à utiliser une variable de classe, parce qu’en réalité elle n’est plus partagée.

Color class»colorNames
  ColorNames ifNil: [self initializeNames].
  ↑ ColorNames

Une autre solution consiste à surcharger la méthode initialize.

Color class»initialize
  ...
  self initializeNames

Si vous adoptez cette solution, vous devez vous rappeler qu’il faut invoquer la méthode initialize après l’avoir définie, par ex., en utilisant Color initialize. Bien que les méthodes côté classe initialize soient exécutées automatiquement lorsque le code est chargé en mémoire, elles ne sont pas exécutées durant leur saisie et leur compilation dans le navigateur Browser ou en phase d’édition et de recompilation.

Les variables de pool(50) sont des variables qui sont partagées entre plusieurs classes qui ne sont pas liées par une arborescence d’héritage. À la base, les variables de pool sont stockées dans des dictionnaires de pool ; maintenant, elles devraient être définies comme variables de classe dans des classes dédiées (sous-classes de SharedPool). Notre conseil : évitez-les. Vous n’en aurez besoin qu’en des circonstances exceptionnelles et spécifiques. Ici, notre but est de vous expliquer suffisamment les variables de pool pour comprendre leur fonction quand vous les rencontrez durant la lecture de code.

Une classe qui accède à une variable de pool doit mentionner le pool dans sa définition de classe. Par exemple, la classe Text indique qu’elle emploie le dictionnaire de pool TextConstants qui contient toutes les constantes textuelles telles que CR et LF. Ce dictionnaire a une clef #CR à laquelle est affectée la valeur Character cr, c.-à-d. le caractère retour chariot ou carriage return.

ArrayedCollection subclass: #Text
    instanceVariableNames: 'string runs'
    classVariableNames: ''
    poolDictionaries: 'TextConstants'
    categor y: 'Collections-Text'

Ceci permet aux méthodes de la classe Text d’accéder aux clefs du dictionnaire directement dans le corps de la méthode, c.-à-d.. en utilisant la syntaxe de variable plutôt qu’une recherche explicite dans le dictionnaire. Par exemple, nous pouvons écrire la méthode suivante.

Text»testCR
  ↑ CR == Character cr

Encore une fois, nous recommandons d’éviter d’utiliser les variables et les dictionnaires de pool.