au CocoaHeads Paris du mois d'Avril

1. Design Patterns
en Cocoa
Presentation CocoaHeads Paris
Avril 2010
par Renaud Pradenc

2. Introduction
Cette présentation est un résumé de la
présentation que j’ai donné le jeudi 8 avril, et
dont le sujet était les Design Patterns. Au
départ, il s’agissait de parler du livre Les
design patterns de Cocoa aux éditions
Pearson, dont j’ai fait la relecture technique
(c’est à dire vérifié que la traduction en
français n’apportait pas d’erreur). La
présentation s’est transformée en une
introduction aux Design Patterns.

3. Le problème posé par la programmation
orientée objet
La conception d’une application orientée objet peut se résumer ainsi:
établir la liste des tâches à réaliser
répartir ces tâches parmi les objets en leur donnant des responsabilités.
Cette seconde étape est la plus difficile, puisqu’il semble qu’elle s’appuie
essentiellement sur l’expérience du développeur; toutefois, on peut dicter
quelques lignes générales telles que:
donner une taille adéquate aux objets, ni trop grands (beaucoup de méthodes
et de variables d’instance), ni trop petits (ce qui complique les connexions
entre objets, et n’aide pas à la compréhension).
préférer la composition (faire appel à d’autres objets) à l’héritage.
Ces principes ne sont toutefois pas suffisants.

4. Les design patterns
Au fil du temps, on a remarqué que les mêmes problèmes de conception revenaient souvent, et qu’on
pouvait les régler d’une façon standardisée.
Ces solutions standardisées sont les design patterns.
Elles présentent trois avantages:
Ne pas réinventer la roue
Inutile de chercher pendant des heures une solution adéquate. Une fois le problème identifié, un livre
nous offre la solution.
Adopter une solution optimale
Il s’agit d’une solution éprouvée, certainement meilleure qu’une autre que vous pourriez imaginer.
Fournir un vocabulaire commun aux développeurs
La communication est essentielle dans la réussite d’un projet logiciel. Utiliser le nom d’un epattern
explique sans ambiguïté de quoi il s’agit.
Pour faire un parallèle, les design patterns sont à la POO, ce que les algorithmes sont aux traitements
des données. Si vous avez besoin de classer des nombres pas ordre croissant, il existe plusieurs
algorithmes connus: bubblesort, quicksort, bucketsort… ces algorithmes ont chacun leurs avantages et
leur défauts (complexité, lenteur, empreinte mémoire), que les autres programmeurs connaissent
Un livre est fondamental sur le sujet: Design Patterns, publié en 1995 (quinze ans… une éternité en
informatique) par quatre auteurs surnommés le Gang of Four. Ce livre expose 23 patterns classés dans
trois catégories: Création, Structure et Comportement.

5. Design Patterns et
Cocoa
Connaître toutes ces design patterns n’est
pas indispensable, l’utilisation de Cocoa nous
imposant déjà plusieurs patterns. D’autres
patterns sont déjà implémentées par les
classes de Cocoa ou le runtime Objective-C.
La réunion Cocoa Heads fut l’occasion d’en
voir trois qui sont parmi les plus courantes:
le singleton, la délégation et enfin le MVC.

6. Singleton
Il s’agit sans doute de la pattern la plus connue. L’idée est que certains objets ne doivent exister
qu’en un seul exemplaire dans une application. Des exemples de tels objets dans Cocoa sont: le
gestionnaire de fichier (NSFileManager), la palette des polices (NSFontPanel) ou encore l’application
(NSApplication).
Pour obtenir cet objet partagé, on appelle une méthode de classe:
+[NSFileManager defaultManager]
+[NSFontPanel sharedFontPanel]
+[NSApplication sharedApplication]
Le principe de l’implémentation d’un singleton est simple: le .m contient une variable statique. Au
premier appel de la méthode de classe, on instancie la classe, on stocke le pointeur dans la variable
statique et on renvoie ce pointeur. Dans tous les appels suivants, on renvoie simplement le pointeur.
Vous trouverez un exemple de code dans ce document:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals
(chapitre «Cocoa Objects», section «Creating a Singleton object»).
Comme vous le verrez, le gros du code consiste à adapter les opérations de gestion mémoire ou de
copie à ce cas particulier où il n’existe qu’une instance de l’objet.

7. MVC — Modèle,Vue,
Contrôleur
L’idée est de séparer les composants visuels (les Vues: fenêtres, boutons, etc.) du code métier
(Modèle: la logique de l’application). Un objet Contrôleur permet de synchroniser les deux couches.
Le but principal de cette démarche est de détacher le modèle de l’interface utilisateur:
Conserver le modèle à part organise l’application rigoureusement. Par exemple, si l’application
possède un bouton «Visiter le site web», il serait tentant de sous-classer le bouton pour ouvrir
l’URL dans le navigateur web. Le jour où un article de menu «Visiter le site web» fait son apparition,
il serait également tentant de sous-classer l’article de menu et simplement copier-coller le code
d’ouverture de l’URL.
La séparation imposée par le MVC dicte qu’il faut mettre une méthode d’ouverture de l’URL dans la
partie modèle, et que le bouton et l’article de menu appellent cette méthode. Toute duplication du
code est à proscrire: cela augmente la complexité et les chances de bogues. Le MVC favorise la
factorisation du code.
L’exemple du diaporama montre une application qui stocke des mesures en millimètres. Sur un
système américain, les mesures sont affichées en pouces, et sur un système français, en mm. C’est la
couche Contrôleur qui s’inquiète de savoir quelle unité utiliser et qui effectue les conversions.
Comme on me l’a fait remarquer pendant la présentation, on pourrait très bien afficher les mesures
dans les deux unités en même temps.
On peut tout à fait imaginer une application en ligne de commande, utilisant le même modèle mais
qui afficherait son résultat sous forme de texte et serait commandé au clavier.

8. La délégation
Cette dernière pattern laisse souvent perplexes les nouveaux venus
à Cocoa, pourtant sa mise en œuvre est simple à comprendre.
Dans l’exemple qui suit, nous voulons contraindre les dimensions
d’une fenêtre. Voici la technique à base d’héritage:

9. La méthode -(void)setFrame:(NSRect)frame
est surchargée dans la classe MyWindow.
En utilisant le principe de la délégation, voici
ce que ça donne:

10. Quand la fenêtre à l’intention de changer de taille, elle appelle la
méthode -(NSSize) windowWillResize:(NSWindow*)window toSize:
(NSSize)proposedFrameSize de son délégué. Celui-ci a alors
l’opportunité de renvoyer une taille différente de celle proposée.
Voici quelques avantages de cette démarche:
NSWindow est une classe complexe, et les programmeurs
d’applications ne disposent pas de son code source. Ils ne connaissent
pas non plus ses méthodes et variables d’instance privées.
Écrire une méthode de délégation est beaucoup plus facile que de
sous-classer NSWindow.
On peut changer de délégué à l’exécution: plutôt que changer
d’algorithme, utilisez un délégué qui implémente un algorithme
différent.
On peut partager un délégué entre plusieurs fenêtres.
La délégation est très courante en Cocoa. Elle prend plusieurs
formes: les data sources (utilisées notamment pour les NS/
UITableView) sont une forme de délégation.

11. Délégué et protocole
Contrairement à d’autres langages objets, Objective-C n’autorise pas l’héritage multiple, c’est à dire qu’une classe
ne peut avoir qu’une classe parente.
Cependant, le langage propose la notion de protocole: il s’agit d’une liste de méthodes qu’un objet doit
implémenter pour être conforme (en Java, les protocoles sont appelés interfaces. On C++, on les considérerait
comme des classes abstraites pures).
Un protocole est un bon moyen de définir la forme d’une méthode déléguée. Pour l’exemple de NSWindow ci-
dessus, Apple n’a pas défini de protocole, mais cela pourrait donner quelque chose comme:
@protocol NSWindowDelegate
@optional
-(NSSize) windowWillResize:(NSWindow*)window toSize:(NSSize)proposedFrameSize;
@end
La directive @optional indique que l’implémentation de la méthode par le délégué est optionnelle. Il existe une
directive @required qui indique un caractère obligatoire. Dans notre exemple, le délégué d’une fenêtre n’est pas
tenu d’implémenter toutes les méthodes déléguées; le comportement par défaut est correct la plupart du temps.
Dans le cas des data sources, sur Mac, il n’existe pas de protocole. Si vous oubliez d’implémenter une des
méthodes nécessaires, vous verrez un message dans la console à l’exécution. Sur Cocoa Touch, Apple impose que
des data sources répondent à un protocole avec plusieurs méthodes @required. L’absence d’une de ces
méthodes provoquera une erreur à la compilation, ce qui est bien mieux.
L’exemple du diaporama montre l’implémentation de la délégation pour une vue personnalisée, jetez-y un œil.

12. Le livre Les design
patterns de Cocoa
Au départ, c’est pour parler du livre que j’avais invité à Cocoa Heads, alors parlons-en !
Soyons honnêtes, ce livre ne vous expliquera pas comment utiliser les design patterns dans vos programmes
Cocoa. C’est avant tout un livre qui explique quels choix de conception ont été effectués dans Cocoa et
pourquoi.
Les deux auteurs travaillent avec Cocoa et son ancêtre NeXTStep depuis des années. Ce sont des membres
fondateurs du site Stepwise, qui fut longtemps un site de référence sur la programmation Cocoa (mais qui a
malheureusement fermé récemment). Ils ont écrit Cocoa Programming, le premier mode d’emploi de Cocoa
vraiment accessible, à une époque où seule la documentation d’Apple existait.
Ce sont vraiment des passionnés de Cocoa, et cela se sent dans la lecture; de fait, le livre est surtout une plongée
dans les arcanes de Cocoa, et c’est pour cela que je le conseillerais à tout programmeur sérieux sur Mac.
Le livre souffre de deux défauts bien réels. D’une part, il y a une volonté de revenir aux design patterns pour
justifier le titre du livre. D’autre part, le livre aurait gagné à être amputé d’un bon tiers: il y a beaucoup de
répétitions, et certains chapitres sont inutiles. C’est un défaut récurent des livres américains, lié à leur culture: il
faut que le client en ait pour son argent, le livre doit donc être épais — alors que c’est de l’information que nous
achetons, pas du papier !
Cela dit, pour la relecture technique, il a fallu que je le lise l’ouvrage de la couverture à la couverture, ce qui
s’avère ennuyeux. Sautez les passages les moins intéressants, et je vous garantis une lecture pleine d’intérêt, qui
approfondira considérablement votre connaissance de Cocoa.

13. Renaud Pradenc
Céroce
www.ceroce.com