Skip to content

17 octobre 2010 | Rédigé par Mathieu

5

Model-View-Controller : le design pattern de référence du dev. iPhone

Si vous vous promenez sur les documentations Apple, sur les autres sites dédiés au développement iPhone ou Mac, ou encore en regardant simplement les codes sources des applis, vous repérerez vite trois termes qui, répétés tels des Mantras de l’informatique moderne, semblent tout aussi puissants que mystérieux : Model , View et Controller.
Après 7 tutoriels iPhone, il est grand temps de faire une petite pause un peu plus théorique dans nos développements et essayer de prendre la mesure de ce design pattern à la base de tout développement sur iOS.

Qu’est-ce qu’un design pattern ?

La définition la plus courante d’un pattern vous laissera probablement sur votre faim :
Un pattern est une solution à un problème dans un contexte.

Soyons plus précis : dans une situation donnée, vous, développeur, avez un but défini que vous souhaitez atteindre. Mais beaucoup d’autres développeurs ont déjà eu cette même problématique. Le design pattern est une conception générique que tout le monde peut appliquer pour atteindre ce but, dans ce contexte. Un design pattern est donc mieux qu’une « best practice », c’est une  conception idéale, testée et approuvée par vos pairs.

Il existe en fait une petite vingtaine de patterns principaux (Stratégie, Singleton, Commande, Patron de méthode, Proxy …), que nous n’allons pas détailler ici mais qui sont extrêmement utiles et font partie de la boîte à outil quotidienne du parfait analyste programmeur, chef de projet technique ou architecte logiciel. Une biblio est disponible à la fin de cet article si vous souhaitez creuser la question.

Retenons donc : un design pattern est un modèle de conception éprouvé pour un problème dans un contexte donné. Son utilisation permet de garantir l’indépendance et la réutilisabilité des objets, mais aussi leur bonne évolution.

Je vous présente, MVC : pas un design pattern, LE design pattern

Le design pattern MVC pour Modèle-Vue-Contrôleur est un pattern composé : c’est à dire qu’il met en oeuvre trois patterns plus simples (Stratégie, Observateur et Composite) mais que nous ne détaillerons pas ici. A vrai dire c’est le roi des patterns composés : mis au point en 1979 dans les laboratoires de recherche Xerox PARC, il décrit une architecture qui organise les interfaces homme machine en trois parties indépendantes et réutilisables :

  • le modèle : le modèle de données, la logique de l’application
  • la vue : présentation des données et interactions avec l’utilisateur
  • le contrôleur : logique de contrôle, gestion des événements, mise à jour du modèle et/ou de la vue

MVC est utilisé partout dans Cocoa Touch. De façon plus générale, il est au coeur de Cocoa, comme il était au coeur de NextStep et du langage SmallTalk. C’est même devenu un tube, la preuve : http://www.youtube.com/watch?v=YYvOGPMLVDo

La vue d’un côté, le modèle de l’autre : le contrôleur fait le lien

Pour une réutilisabilité maximum et garantir l’évolution des objets, il faut des frontières claires. C’est ce qu’impose le MVC. L’objet contrôleur devient alors le ciment et le lien pour afficher dans la vue les données du modèle. Un peu comme ça :

En formalisant les choses de manière moins gloutonne plus professionnelle :

  1. L’utilisateur interagit avec la vue, en saisissant une valeur ou en cliquant sur un bouton, par exemple
  2. Le contrôleur reçoit les actions de l’utilisateur, les interprète et demande au modèle de modifier son état
  3. De même, suite à cette action, le contrôleur peut avoir besoin de demander à la vue de changer en conséquence (activer ou désactiver un champ, etc.)
  4. Le modèle informe la vue de son changement d’état, suite à une modification liée à un clic de bouton ou même à une modification interne (fin d’un chargement, etc.)
  5. La vue demande son état au modèle, que ce soit suite à une information du modèle ou du contrôleur

Un exemple plus concret pour fixer les idées

C’est encore un peut abstrait ? Prenons l’exemple d’un lecteur MP3, comme celui-ci :

Identifions les acteurs dans le MVC :

  • La vue c’est l’écran ci-dessus avec l’affichage du nom de l’artiste, les boutons Lecture, suivant et Précédent, le contrôle du volume
  • Le modèle est un objet qui a la charge de lire le fichier MP3 et d’envoyer les informations au système de son
  • Le contrôleur est un objet qui va faire le lien entre les deux

Avec notre schéma précédent, cela nous donne :

  1. L’utilisateur a très envie d’écouter de la musique, il appuie sur le bouton « Lecture »
  2. Le contrôleur reçoit l’information « le bouton Lecture a été cliqué », il demande au modèle de commencer la lecture. La musique démarre.
  3. Le contrôleur demande à la vue de transformer le bouton « Lecture » en un bouton « Pause » et d’afficher les informations du morceau en lecture.
  4. Le morceau a été lu en entier, le modèle informe la vue qu’il a commencé la lecture du morceau suivant
  5. La vue a été informée du changement de morceau et demande au modèle les information du nouveau morceau en lecture.

Le développement iPhone adopte le modèle MVC

Nous avons déjà eu affaire avec le MVC dans les précédents tutoriels iPhone, nous ne cesserons pas de l’utiliser par la suite.

  • La vue est, dans l’immense majorité des cas, prise en charge par Interface Builder, qui nous permet de tout designer sans une ligne de code : ajouter des éléments, gérer leur positionnement.
  • Nous n’avons pas encore vu de modèle à proprement parler, mais nous aurons l’occasion d’en créer, et ce dès le tutoriel n°8. Nous verrons aussi que les données peuvent être prises en charge par CoreData, moteur de données extrêmement puissant.
  • Les contrôleurs, ça on en a déjà vu : UIViewController, UINavigationController, UITabBarController, … C’est pour l’instant là où nous avons codé le plus, puisque nous avons essentiellement des applications qui réagissent à l’utilisateur.

Deux questions qu’il vaut mieux poser tout de suite

1ère question : Dans le tutoriel n°4 – l’application calculette, nous n’avons pas utilisé de modèle, pourquoi ? Un modèle n’est pas utile dans ce cas ?

C’est un choix plus éditorial que de bonne conception que de ne pas utiliser de modèle dans ce tutoriel. L’objectif était de faire le plus simple possible, quitte à créer des lourdeurs et à sacrifier complètement la réutilisabilité du code mis en place. Par exemple, il est impossible d’intégrer cette calculette dans une autre appli ou même dans une autre vue de cette application sans tout recoder.

2nde question : Au final le contrôleur n’est qu’un simple passe-plat, non ? Pourquoi ne pas garder qu’un modèle et une vue et se séparer des intermédiaires ?

Le contrôleur ne fait pas que passer les plats : il est chargé d’interpréter les actions de l’utilisateur dans la vue pour manipuler le modèle en conséquence. Deux raisons expliquent qu’il n’est pas souhaitable de confier à la vue le soin de manipuler le modèle. La première est que cela imposerait à la vue d’avoir deux boulots : gérer l’interface et manipuler le modèle. La seconde est que cela imposerait un couplage fort entre la vue et le modèle, il serait alors impossible de modifier le modèle sans modifier la vue, ou l’inverse. Un couplage faible via un contrôleur vous assure une évolution plus souple des éléments par la suite. En gros : pas besoin de tout recoder parce que j’ai ajouté une fonctionnalité.

Envisager le MVC dans une application avec un enchaînement d’écrans

Une application iPhone est souvent composée de différents écran enchaînés entre eux. Un exemple : je consulte une liste d’éléments, et quand je sélectionne un événement, je consulte le détail de l’élément. Dans cet exemple, le MVC joue pleinement son rôle de patron de conception :

  • Ma liste présente une série d’éléments. Un contrôleur récupère un tableau d’objets modèles représentant des éléments. Il trie ces objets (par nom, etc.) et les envoie à la vue qui sera en charge d’afficher.
  • Quand l’utilisateur sélectionne un élément dans la vue, le contrôleur se charge de pousser le contrôleur de détail en lui passant l’objet modèle à détailler
  • le contrôleur de détail instancie une vue et présente les éléments du modèle qui lui a été passé. Il peut aussi prendre en charge des modifications, il charge l’objet modèle de se transformer en conséquence (la vue propose un champ pour changer le nom de l’élément, le contrôleur récupère la nouvelle valeur de la vue et modifie le modèle en conséquence)
  • Quand l’utilisateur appuie sur le bouton « Précédent » pour revenir à la liste, le contrôleur de liste reprend la main et rafraîchit les données. Le modèle modifié envoie son nouveau nom et la liste présentée sera à jour des modifications.

Si ce n’est pas encore tout à fait clair, un exemple sera abordé dès le tutoriel suivant.

Aller plus loin

Ce tutoriel n’a pas la prétention d’être exhaustif et de tout vous apprendre sur le MVC mais bien de vous initier à cette conception que vous retrouverez dans la plupart de vos développements. Si vous souhaitez aller (beaucoup) plus loin, je vous recommande les ouvrages suivants :

Pour conclure, adopter le Model-View-Controller, apporte de nombreux avantages pour structurer votre architecture de code, et sa maîtrise vous assurera de concevoir des applications, plus réutilisables, plus faciles à faire évoluer. Un dernier avantages des design patterns est qu’ils représentent un vocabulaire commun  pour échanger avec les autres concepteurs. Les commentaires ci-dessous sont l’occasion de faire la preuve de cette affirmation :) Merci !

Découvrez d'autre articles de la catégorie Tutoriels iPhone

Encore un peu de lecture :

5 Commentaires Poster un commentaire
  1. 27 oct 2010

    petit pose sympa qui nous renvois dans les bancs d’école :) Merci

  2. 29 oct 2010

    @azur audio : ce sont les macarons qui te font retourner en enfance ? ;-)

  3. tirlip
    26 fév 2011

    le modèle MVC est aussi appliqué dans la création d’applications en général et celles webisées en particulier. il existe un tas de framework PHP par exemple qui illustrent cela.
    j’ai utilisé récemment Yii et c’est très « logique » dans l’implémentation.
    bref, ma question porte plutôt sur l’environnement android, comment s’implémente-il ?
    il y-a-t-il des précautions particulières ?
    merci d’avance
    Rico

Trackbacks & Pingbacks

  1. Les tweets qui mentionnent Model-View-Controller : le design pattern de référence du dev. iPhone | Tuto Mobile -- Topsy.com
  2. Liste et détails : créer une application multivues (1/2) [Tutoriel iPhone n°8] | Tuto Mobile

Une question, une suggestion, une opinion? Partagez ce que vous pensez, laissez un commentaire.

(obligatoire)
(obligatoire)

Note: Votre adresse email ne sera jamais publiée.

Suivez les réponses aux commentaires