Comment utiliser le contrôleur de modèle-vue (MVC) Design Pattern pour développer une application iOS - mannequins

Les frameworks iOS sont orientés objet. Un moyen facile de comprendre ce que cela signifie vraiment est de penser à une équipe travaillant dans un bureau. Le travail qui doit être fait est divisé et assigné à chaque membre de l'équipe (dans ce cas, les objets). Chaque membre de l'équipe a un travail et travaille avec les autres membres de l'équipe pour faire avancer les choses.

De plus, un bon membre de l'équipe ne se soucie pas de savoir comment les autres membres font leur travail, mais seulement de le faire selon la division du travail convenue. De même, un objet en programmation orientée objet s'occupe de ses propres affaires et ne se soucie pas de ce que fait l'objet dans la cabine virtuelle voisine, tant qu'il fera ce qu'il est censé faire lorsqu'on lui demandera de le faire.

La programmation orientée objet a été développée à l'origine pour rendre le code plus facile à maintenir, réutilisable, extensible et compréhensible en encapsulant toutes les fonctionnalités derrière des interfaces bien définies. Les détails réels de la façon dont quelque chose fonctionne (ainsi que les données qu'il utilise pour faire ce travail) sont cachés, ce qui rend la modification et l'extension d'une application beaucoup plus facile.

Génial - jusqu'à présent - mais une question embêtante peste encore les programmeurs:

Comment décidez-vous des objets et de ce que chacun fait?

Parfois, la réponse à cette question est assez simple - utilisez simplement le monde réel comme modèle. (Eureka!) Mais quand il s'agit d'une structure de programme générique, comment ne décidez-vous de ce que les objets devraient être? Ce n'est peut-être pas si évident.

Le modèle MVC est un moyen bien établi de regrouper des fonctions d'application en objets. Des variantes en sont au moins depuis les débuts de Smalltalk, l'un des tout premiers langages orientés objet. MVC est un modèle de haut niveau: il traite de l'architecture d'une application et classe les objets en fonction des rôles généraux qu'ils jouent dans une application, plutôt que de se limiter à des détails spécifiques.

Le pattern MVC crée, en effet, un univers miniature pour l'application, peuplé de trois types d'objets distincts. Il spécifie également les rôles et les responsabilités pour les trois types d'objets et spécifie la manière dont ils sont censés interagir les uns avec les autres. Pour rendre les choses plus concrètes (c'est-à-dire, pour ne pas exploser la tête), imaginez une grande et belle télévision à écran plat de 60 pouces. Voici l'essentiel:

• Objets du modèle: Ces objets constituent ensemble le contenu "moteur" de votre application. Ils contiennent les données et la logique de l'application, ce qui rend votre application plus qu'un joli visage.Dans l'application RoadTrip, par exemple, le modèle conserve une liste d'événements et de vues, ainsi que le nom et l'emplacement de la destination et une image de fond à utiliser.

  Vous pouvez penser au modèle (qui peut être un ou plusieurs objets qui interagissent) comme un programme de télévision particulier, qui, franchement, ne prête pas attention au téléviseur qu'il affiche sur.

  En fait, le modèle ne devrait pas donner envie. Même s'il possède ses données, il ne devrait pas avoir de connexion avec l'interface utilisateur et devrait être parfaitement ignorant de ce qui est fait avec ses données.

• Afficher les objets: Ces objets affichent des éléments à l'écran et répondent aux actions de l'utilisateur. Presque tout ce que vous pouvez voir est une sorte d'objet de vue - la fenêtre et tous les contrôles, par exemple.

  Vos points de vue savent comment afficher les informations qu'ils reçoivent de l'objet modèle et comment obtenir des informations de la part de l'utilisateur dont le modèle peut avoir besoin. Mais la vue elle-même ne devrait rien savoir du modèle. Il peut gérer une requête pour afficher certains événements, mais il ne s'embarrasse pas de ce que cette requête signifie.

  Vous pouvez considérer la vue comme un écran de télévision qui ne se soucie pas du programme affiché ou du canal que vous venez de sélectionner.

  Le framework UIKit fournit différents types de vues.

  Si la vue ne connaît rien au modèle et que le modèle ne sait rien de la vue, comment faire passer les données et autres notifications de l'une à l'autre? Pour démarrer cette conversation (Modèle: "Je viens de mettre à jour mes données." Voir: "Hé, donne moi quelque chose à afficher", par exemple), vous avez besoin du troisième élément du triumvirat MVC, le contrôleur.

• Objets du contrôleur: Ces objets connectent les objets vue de l'application à ses objets modèles. Ils fournissent aux objets de vue ce qu'ils doivent afficher (en les récupérant depuis le modèle) et fournissent également au modèle une entrée de l'utilisateur à partir de la vue.

  Vous pouvez considérer le contrôleur comme le circuit qui tire le show du câble, puis l'envoie à l'écran ou demande un show à la carte.

Avec Xcode, les objets modèle et vue sont souvent construits avec des interfaces utilisateur graphiques telles que Interface Builder pour les vues et les contrôleurs de vues et l'éditeur de modèles de données pour les objets de données de base. Les contrôleurs sont presque toujours construits avec du code. Construire un objet contrôleur est la partie de MVC qui, pour de nombreux développeurs, "se sent" comme le codage traditionnel.

L'architecture de base de l'application ressemble à ceci.

Lorsque vous pensez à votre application en termes d'objets de modèle, de vue et de contrôleur, l'infrastructure UIKit commence à avoir un sens. Comprendre le cadre de cette façon commence également à lever le brouillard sur l'endroit où aller au moins une partie de votre comportement spécifique à l'application.

Dans Objective-C, les classes incluent des variables d'instance, des propriétés et des méthodes (qui peuvent accéder aux variables d'instance d'une classe). Les classes concernent les fichiers de votre projet qui contiennent du code. Les classes sont types dans votre programme.

Les objets, en revanche, existent à l'exécution et sont instances d'une classe.Vous pouvez considérer une classe comme un plan pour construire un objet de ce type.