Conception modèle-donnée-interface... (réponse à  ClicCool)

BruBru Membre
[size=8pt](Je préfère démarrer un nouveau sujet pour répondre à  ClicCool)[/size]

dans 1105128707:

En fait mon petit Bru à  moi (puisque ça marche je m'y mets aussi ;) ), l'idéal serait peut-être que tu tuyaute notre cher petit Alex à  nous (y'a pas d'raison pour qu'y'ait que Bruno qu'y y ait droit ;) ) sur un (des) cours, méthodes, tuto qui permettent d'apprendre à  transformer un cahier des charges (Qu'Alex semble savoir établir au préalable) en un projet suffisament bien défini pour qu'il ne se retrouve pas toujours à  réécrire tout (ou presque) 4 ou 6 fois pour chacuns de ses projets.

Sans doutes, du reste, ça ne ferait pas de mal d'ajouter à  O.C. un forum spécialisé dans la conception d'un bon modèle-Objet d'une bonne structure de contrôleurs etc... à  partir de l'idée voire du cahier des charges .../... ?

Nombreux sont ceux qui se lancent d'emblé dans le code à  l'aveugle sans avoir défini un minimum la structure de leur projet.
Il manque systématiquement, dans les Forums ou mailings-listes ... de prog. cette étape fondamentale à  la conception d'un bon projet.


Le problème de tout "débutant" en programmation, c'est de commencer par la fin (l'interface graphique). C'est comme un architecte qui construit une maison en posant les 4 murs, le toit, la porte et les fenêtres sans penser aux pièces qui seront à  l'intérieur, aux murs porteurs qu'il faudra prévoir, aux arrivées d'eau ou d'électricité qu'il faudra installer.

Une fois cette maison construite, et bien notre architecte va se mettre à  "bricoler" pour essayer de caser comme il le peut les pièces, les murs... Il met une pièce : merde, y'a trop de fenêtres et on ne peut plus mettre de meuble, alors c'est pas grave, je casse un bout de mur et je déplace une porte. Merde, la porte empiète sur l'arrivée d'eau. Pas de panique, je déplace l'arrivée. Merde, l'eau n'arrive plus dans la cuisine... etc, etc...

Y'a pas de tuto à  faire pour apprendre ça. C'est juste quelques règles à  établir :
- un bon projet sous Xcode ne doit pas se faire en ouvrant immédiatement Interface Builder.
- regarder comment on fera la même chose avec un crayon, des papiers, des classeurs, des boites de rangement si les ordinateurs n'existaient pas. Ensuite essayer de calquer ça dans un schéma informatique.
- écrire beaucoup beaucoup beaucoup sur papier ce qu'on veut faire : des petits dessins par exemple pour symboliser les données et leurs relations, pour schématiser les traitements. Ensuite relire ça le lendemain pour voir si y'a rien d'oublié, et si c'est toujours compréhensible.

Pour exemple, voici le bout de papier que j'ai écrit un matin dans le train quand j'ai pensé à  Favouille et à  son carnet de plongée...

.

[Fichier joint supprimé par l'administrateur]

Réponses

  • muqaddarmuqaddar Administrateur
    00:32 modifié #2
    Je suis OK avec tout ce que tu as écrit Bru, mais pour l'instant, ce schéma me fait plus penser à  un modèle avant de créer une BDD relationnelle que de savoir quelle classe fera quoi, et héritera de quelle autre...etc.
    Mais je suis sûr que tu vas y venir. ;)
  • BruBru Membre
    00:32 modifié #3
    Les notions de création de tables et de leurs relations dans une BDR est proche d'un modèle de conception d'une classe et des relations qu'elle entretiendra avec les autres.

    Les objets d'une classe ne sont que des conteneurs à  données tout comme l'est une table dans une BDR, tout comme les méthodes de la classe pourraient être assimilées à  des procédures stockées.

    Quand à  l'héritage, tout dépend de beaucoup de paramètres... Comme ici je parle de données, généralement on part de zéro (donc on hérite que de NSObject)... Pour moi l'héritage ne se conçoit que lorsqu'on veut modifier le comportement d'une classe préexistante, ou lorsqu'on veut l'enrichir de méthodes qui n'existent pas. (voir le sujet de Nucleus qui résume aussi ma philosophie POO).

    .
Connectez-vous ou Inscrivez-vous pour répondre.