Version imprimable
Bonjour,
il y'a sûrement des développeurs dans le coin qui ont la science et l'expérience et qui pourraient m'éclairer et qui pratique cela tous les jours...
Voilà, ce qui semble pour moi un mystère : c'est comment déterminer les classes à partir d'un énoncé; ça me semble trés difficile...mais il y'a sûrement des astuces...Lesquelles, s'il vous plaît...
merci
A la base, une classe = un concept "buisness" qui ressort de ton interview avec un client. Ex: ton client te demande un application pour gérer ses différent appartement, il te dit qu'il faut régulièrement faire des travaux dedans, qu'il dois savoir gérer donc ses locataires, leurs demandes, les travaux et le facture.
Ben relit çà, t'as plusieurs classes qui ressortent directement:
Appartement (il a quoi? Une adresse, un ou plusieurs locataires, une série de travaux fait dedans, ....)
Travail (où?, qui fait les travaux, quelles sont les factures associées)
Demande (Qui? Pour quel appartement? Pour quelle raison? Déjà fait ou pas?)
Locataire (Appartement, téléphone? bail? Nom?)
Factur (Pour quoi? Quel montant? Payées? Qui doit payer?)
Voilà, à partir de là tu raffine ton interview avec ton client pour préciser ces points et, au fur et à mesure, ton modèle buisness se rafine, après il faut faire tn shéma de class, peut être ajouter des classes "techniques" qui ne sont pas liées au besoin du client mais qui sont liée à la réalisation de l'application.
Dans un but non-commercial, demande toi simplement ce que tu cherche à faire.
De quoi est fait ou a besoin telle ou telle chose ?
Par exemple, je m'entraîne actuellement avec un tchat sur console pour la communication internet (je fait joujou avec les socket :)).
J'ai commencé par le serveur et je me suis demandé ce dont était fait un tel serveur. Il y a un serveur qui distribue des services aux clients. Et pour me permettre de garder le contrôle sur le serveur, j'y ajoute un écouteur pour lire mes commandes sur la console du serveur.
Au final j'ai 4 classes au minimum. Je peux rajouter une classe de management des clients afin de mémoriser des comptes clients ... La force de la programmation orienté objet, c'est que chaque chose peux être modélisé d'une façon ou d'une autre.
Un petit "truc" qui peux t'aider, c'est de "dessiner" ton problème sur un papier :)
C'est marrant c'est là qu'on voit que je suis tres formatté...
Moi en général, en plus de tout ça , je pense "Base de données" même si elle n'est pas nécessaire pour le projet que je fais.
Je me dis : "si je devais stocker ce que je fais , comment je mettrais mes bases ?"
=> apres je determine en fonction des données que j'ai, si elle doivent être dans la même classe car elles sont liées ou si je peux les réutiliser ailleurs et donc une table rien que pour elles.
Je complete en me disant " ok j'ai besoin de fonctions, méthodes non ?"
=> là je regarde si j'ai les classes qui faut pour mettre les méthodes ou si de nouvelles classes émergent ....;
apres je reprends mon problème, en ayant dessiné mes classes sur une feuille, et je prends les cas principaux d'utilisation et je vérifie qu'ils passent par mes classes ...