Etapes de la conception d'une Appli
Mick
Membre
Bonjour,
Question très simple, mais néanmoins importante pour moi :
Lorsque vous concevez une application, dans quel ordre pensez-vous l'architecture ?
-> d'abord le modèle de donnée ?
-> d'abord la couche vues (que doit pouvoir "voir" l'utilisateur, sur quoi doit-il pouvoir agir ?)
-> les deux simultanément ?
Comment commencez-vous "l'action" ? Vous créez d'abord l'interface graphique ? Vous créez d'abord la couche modèle ?
vous créez simultanément les contrôleurs et les vues ?
Ces questions vous paraissent sûrement débiles, mais c'est pour prendre de bonnes habitudes "de pros"...
Question très simple, mais néanmoins importante pour moi :
Lorsque vous concevez une application, dans quel ordre pensez-vous l'architecture ?
-> d'abord le modèle de donnée ?
-> d'abord la couche vues (que doit pouvoir "voir" l'utilisateur, sur quoi doit-il pouvoir agir ?)
-> les deux simultanément ?
Comment commencez-vous "l'action" ? Vous créez d'abord l'interface graphique ? Vous créez d'abord la couche modèle ?
vous créez simultanément les contrôleurs et les vues ?
Ces questions vous paraissent sûrement débiles, mais c'est pour prendre de bonnes habitudes "de pros"...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
La conception d'une application est capitale. Notamment pour la maintenance et l'évolution.
Pour ma part:
- je commence avec papier et crayon et je définis mon modèle de données (bases, tables, relations entre modèles)
- je poursuis sur papier et je dessine mes interfaces (même si c'est fait rapidement, et parfois moche, ça aide beaucoup pour la suite)
Puis au niveau du code:
- je code d'abord mes classe modèles avec les méthodes adéquates
- je code souvent quelques singletons qui vont interagir avec ces modèles (mais on peut directement taper dans le modèle)
- je passe enfin à mes controllers et mes vues en me rapportant à mes schémas
Bien entendu, une app de gestion de données n'aura pas forcément la même architecture qu'une app utilitaire...
2 - Ensuite bien définir les interactions utilisateurs, et avec quelles parties de ton modèle elles agissent te permettra de définir les différents composants de ton interface graphique (Vues et ce qu'elles comportent), et quel contrôleur gèrera quelle(s) partie(s).
3 - Quand ces deux premiers points te semblent bien, tu peux te lancer dans la phase de codage. D'abord les classes modèles, ensuite les classes contrôleurs et les éléments d'interfaces. (MVC)
Première passe
J'essaye d'avoir une idée générale de ce que va donner l'appli: quelles sont les grands blocs fonctionnels et comment seront-ils organisées dans la partie "métier" et dans la partie IHM. Pour l'instant, je travaille avec des feuilles A4 et un gros feutre qui m'empêche de donner trop de détails.
Deuxième passe
Le processus devient itératif.
Je me concentre sur une seule fonctionnalité, en codant d'abord le modèle. Pour le mettre au point, j'utilise OCUnit. Seulement après, je conçois l'IHM.
Si on commençait par l'IHM, on se planterait certainement: oublier des dépendances, on ne peut pas faire ceci sans faire cela, il y a un paramètre là , qu'on n'a pas pris en compte, et puis finalement ça ne peut pas marcher ainsi, etc. Du coup, on remanierait le modèle sans arrêt jusqu'à ce qu'il soit bon en changeant l'IHM à chaque fois. Il vaut mieux avoir un modèle qui tient la route dès le départ. On gagne beaucoup de temps, et le logiciel sera de meilleure qualité.
Puis je passe à la fonctionnalité suivante.
P.S.
J'évite absolument l'utilisation des singletons. Les singletons ont de gros défauts. Par exemple, dans les tests unitaires, comment injecte-t-on des données de test si tous les objets vient piocher dans le tas de données "réelles" ? D'un point de vue conceptuel, les singletons promeuvent les trains de méthodes:
NSString *titreLivre = [ModeleSingleton sharedModele].livre.couverture.titre.texte;
Alors que passer la couverture à CouvertureViewController rend explicite ses dépendances et ne nécessite pas de le modifier si la structure du livre venait à changer.
Mais je ne procède pas ainsi.
Par exemple, j'ai un singleton 'Cave'.
=> Je demande à Cave ma liste de vins.
=> Cave crée les instances de la classe Modèle Vin, elle ne les modifie donc pas, et si je modifie Vin, je n'aurais rien à modifier dans le Singleton Cave. Elle met tout ça dans un array et Cave me renvoie mon array de vins.
Voilà , c'était un exemple.
Ta classe Cave pourrait avoir une méthode -initWithDataBaseAtPath:, et être instancié par l'AppDelegate.
Avantages:
- on peut ouvrir plusieurs Caves dans le logiciel, voire copier des données d'une Cave à l'autre.
- pas besoin de surcharger les méthode des gestion de la mémoire, nécessaire pour faire un vrai singleton.
- la classe Cave ne dépend plus du chemin de la BdD; elle devient réutilisable, ce qui est intéressant pour une classe de la couche modèle.
Le singleton est la tarte à la crème de la POO. Cette design pattern est utile quand on ne peut clairement pas avoir plusieurs instances d'un objet (par exemple UIApplication, UIDevice), mais autrement, elle ne présente que des défauts.
Mais d'abord definir au mieux ce que l'on veut faire.
Apple conseille de faire un pitch en une ou deux phrases maximum (pour une app iPhone).
Par exemple : une appli qui permet de trouver des idees de dessert facile et rapide a realiser.
Après quand tu décides d'ajouter des fonctionnalités, tu les confrontes à ton idée de départ pour éviter de partir dans tous les sens.
Ensuite, Je dessine l'interface avec un papier et un crayon (toujours en ayant le pitch en tête).
Je fais le modèle de donnée en parallèle.
Idéalement le modèle de donnée et l'Interface graphique sont indépendants.
En fait, plus tu as de contraintes (performances, accès distants) moins c'est vrai donc c'est pas mal de faire des allers/retours entre les deux pour vérifier que tout fonctionne bien ensemble.
En fait le mieux c'est de faire ce que tu veux quand t'en a envie, par exemple dès que t'as des idées sur le sujet.
T'as même le droit de coder avant d'avoir finist la conception. Par contre, il faudra être prêt à jeter le code ou a le réorganiser fortement si la conception l'impose.
En fait c'est plutôt même conseillé quand tu débutes de faire des petits snippets de code pendant la phase de conception pour vérifier que les API fonctionnent comme tu l'as imaginé.
Par exemple, les API Apple sont très orientés vers l'asynchronisme, si tu n'as pas bien intégré la notion avant de concevoir des interfaces, tu risques de te planter.
Merci pour vos conseils. Je ne suis pas un pro, bien que j'ai déjà quelques petites applis non commerciales à mon actif. Je suis encore un petit débutant
D'ailleurs j'aurais des questions à ce sujet : comment techniquement pouvoir vendre une appli ? est-il nécessaire de fonder une "société" ?...
Tu peux être auto-entrepreneur, en nom propre ou sans statut (et ajouter tes bénéfices à ta déclaration d'impôts dans certaines cases).
Il y a déjà des discussions là -dessus sur le forum.
:P si ça ne sert qu'a vous et votre beauf, ne faites rien, ou alors pour le plaisir!
Exemple concret : j'imagine une appli de gestion d'un établissement scolaire. Un utilisateur peut-être un surveillant, un prof, un membre de l'administration => On voit déjà que l'interface graphique doit proposer des vues différentes d'une part, mais on entrevoit aussi en même temps qu'il va falloir un modèle de donnée qui permet de créer des "personnels" avec un attribut "fonction" qui peut-être "proviseur" "enseignant", ...
Donc je me demandais si vous concevez ainsi votre architecture (vue et modèles simultanément, puis contoleurs pour gérer tout ça)
J'ai l'impression qu'il n'y a pas vraiment de vérité vraie, et que cela dépend grandement du type d'appli concerné. La seule vérité vraie, c'est qu'on doit déjà avoir une très bonne définition des "besoins" avant de double cliquer sur notre petit marteau sur fond bleu.
En tout cas merci de vos contributions, les pros !