Design patterns
Télécharger en tant que KEY, PDF3 j'aime804 vues
Cette présentation aborde les design patterns en Cocoa, mettant en avant leur importance dans la programmation orientée objet. Les design patterns fournissent des solutions standardisées à des problèmes récurrents, facilitant la communication entre développeurs et évitant la redondance dans le code. Trois patterns clés sont discutées : le singleton, le modèle-vue-contrôleur (MVC) et la délégation, chacun ayant ses propres avantages et applications dans Cocoa.
![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.](https://image.slidesharecdn.com/designpatterns-100426033001-phpapp02/85/Design-patterns-6-320.jpg)
Design patterns
- 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