Comment concevez-vous des projets orientés objet?
Je travaille sur un grand projet (pour moi) qui comportera de nombreuses classes et devra être extensible, mais je ne sais pas comment planifier mon programme ni comment les classes doivent interagir.
J'ai suivi un cours OOD quelques semestres en arrière et j'ai beaucoup appris de ce cours; comme l'écriture UML et la traduction de documents d'exigences en objets et en classes. Nous avons aussi appris les diagrammes de séquence, mais d’une manière ou d’une autre, j’ai manqué la conférence ou quelque chose du genre, ils ne sont pas restés fidèles à moi.
Lors de projets précédents, j’ai essayé d’utiliser des méthodes que j’ai apprises pendant le cours, mais qui finissent généralement avec un code qui dit que dès que je peux dire "ouais ça ressemble à ce que j’avais en tête", je n’ai aucune envie de creuser pour en ajouter. nouvelles fonctionnalités.
J'ai une copie de Steve McConnell Code Complete que j'entends continuellement est incroyable, ici et ailleurs. J'ai lu le chapitre sur le design et il ne semblait pas sortir l'information que je cherchais. Je sais qu'il dit que ce n'est pas un processus sobre, qu'il est principalement basé sur des heuristiques, mais je n'arrive pas à prendre toutes ses informations et à les appliquer à mes projets.
Alors que faites-vous pendant la phase de conception de haut niveau (avant de commencer à programmer) pour déterminer quelles sont les classes dont vous avez besoin (en particulier celles qui ne sont pas basées sur des "objets du monde réel") et comment vont-elles interagir entre elles? autre?
Plus précisément, quelles sont les méthodes que vous utilisez? Quel est le processus que vous suivez qui donne généralement un bon design épuré qui représentera fidèlement le produit final?
Les étapes que j'utilise pour la conception initiale (obtenir un diagramme de classes) sont les suivantes:
Rassemblement des exigences. Parlez au client et expliquez les cas d'utilisation pour définir les fonctionnalités que le logiciel devrait avoir.
Composez un récit des cas d'utilisation individuels.
Parcourez le récit et mettez en surbrillance les noms (personne, lieu, chose), en tant que classes et verbes candidats (actions), en tant que méthodes/comportements.
Supprimez les noms en double et extrayez les fonctionnalités communes.
Créez un diagramme de classes. Si vous êtes un développeur Java, NetBeans 6.7 de Sun dispose d'un module UML qui permet la création de diagrammes ainsi que l'ingénierie aller-retour et il est GRATUIT. Eclipse (une source ouverte Java IDE) dispose également d’un framework de modélisation, mais je n’ai aucune expérience en la matière. Vous pouvez également essayer ArgoUML, un outil open source.
Appliquez les principes OOD pour organiser vos classes (supprimez les fonctionnalités communes, établissez des hiérarchies, etc.)
Je n'ai pas encore assez de réputation pour faire des commentaires (membre aujourd'hui) ou je voudrais juste commenter la réponse de Scott Davies. En plus de ce qu'il avait à dire:
Avant de commencer, assurez-vous de savoir en quoi consiste votre programme. Qu'est-ce que est votre programme? Que fera-t-il pas? Quel problème tente-t-il de résoudre?
Votre première série de cas d'utilisation ne devrait pas être une liste exhaustive de tout ce que le programme finira par faire. Commencez par le plus petit ensemble de cas d'utilisation que vous pouvez imaginer, qui capture toujours l'essence de l'objectif de votre programme. Pour ce site Web, par exemple, les principaux cas d'utilisation pourraient être se connecter, poser une question, répondre à une question, et voir les questions et réponses. Rien sur la réputation, le vote ou le wiki de la communauté, mais l'essence même de ce que vous visez.
Au fur et à mesure que vous proposez des classes potentielles, ne pensez pas uniquement à leur nom, mais à leurs responsabilités. J'ai trouvé qu'il s'agissait de la plus grande aide pour comprendre le lien entre les classes lors de l'exécution du programme. Il est facile d'établir des relations comme "un chien est un animal" ou "un chiot a une mère". Il est généralement plus difficile de comprendre les relations décrivant les interactions d'exécution entre les objets. Les algorithmes de votre programme sont au moins aussi importants que vos objets et ils sont beaucoup plus faciles à concevoir si vous avez décrit le travail de chaque classe.
Une fois que vous avez cet ensemble minimal de cas d'utilisation et d'objets, commencez à coder. Obtenez quelque chose qui fonctionne réellement le plus tôt possible, même s'il ne fait pas grand chose et ressemble probablement à de la merde. C'est un point de départ qui vous obligera à répondre à des questions que vous pourriez oublier.
Maintenant, revenez en arrière et choisissez plus de cas d'utilisation, décrivez leur fonctionnement, modifiez votre modèle de classe et écrivez plus de code. Comme pour votre première coupe, prenez le moins de temps possible tout en ajoutant quelque chose de significatif. Rincer et répéter.
Juste mes deux cents. J'espère que c'est utile.
Lorsque j'en ai l'occasion, j'utilise normalement ce que j'appelle la "règle des trois itérations".
Dans la première itération (ou démarrage), je conçois la disposition générale de l'application en fonction des objets du modèle, des algorithmes et de l'attendu (vraiment attendu, pas peut-être attendu ) directions futures. Je n'écris pas de documents de conception, mais si je dois coordonner plusieurs personnes, il vous faudra bien sûr une description succincte de la procédure, ainsi qu'une analyse des dépendances et une estimation approximative du temps nécessaire. Essayez de minimiser cette phase si, comme moi, vous préférez une méthode plus agile. Il existe des cas où une phase de conception forte est nécessaire, en particulier lorsque tout est connu et véridique concernant la logique de votre programme et si vous envisagez de nombreuses interactions entre les fonctionnalités de votre code. Dans ce cas, les cas d'utilisation ou les user stories fournies sont une bonne idée de haut niveau, en particulier pour les applications à interface graphique. Pour les applications en ligne de commande, et en particulier les bibliothèques, essayez d’écrire des "histoires de programme" dans lesquelles vous codez contre la bibliothèque que vous devez développer et vérifiez son apparence. Ces programmes deviendront des tests fonctionnels de votre bibliothèque une fois terminés.
Après cette première itération, vous aurez une meilleure compréhension de la façon dont les choses interagissent, vous en sortez les détails et les points difficiles, vous avez résolu les problèmes liés à un patch de ruban adhésif. Vous êtes prêt à utiliser cette expérience pour améliorer, nettoyer, polir, diviser ce qui était trop volumineux, fusionner ce qui était trop fragmenté, définir et utiliser des modèles de conception, analyser des goulots d'étranglement de performances et des problèmes de sécurité non triviaux. En général, tous ces changements auront un impact énorme sur les tests unitaires que vous avez écrits, mais pas sur les tests fonctionnels.
Lorsque vous aurez terminé cette deuxième étape, vous aurez un petit bijou, bien testé, bien documenté et bien conçu. Maintenant, vous avez à la fois l'expérience et le code pour effectuer la troisième itération, étendre. Vous allez ajouter de nouvelles fonctionnalités et des cas d'utilisation pour améliorer votre application. Vous trouverez des points difficiles et vous entrerez éventuellement dans une quatrième itération, analogue à la seconde. Rincer et répéter.
Ceci est mon approche générale de la conception de logiciels. Il ressemble à la conception en spirale, avec de courtes itérations de trois mois et des éléments de développement Agile, qui vous permet d’apprendre les problèmes et d’apprendre à connaître votre logiciel et son domaine d’application. Bien sûr, il s’agit d’une question d’évolutivité. Par conséquent, si l’application est si vaste et implique des centaines de développeurs, les choses sont un peu plus complexes que cela, mais au final, je suppose que l’idée est toujours la même, diviser et impera .
Donc en résumé:
- En itération un, vous en goûtez et apprenez
- En itération deux, vous nettoyez votre produit et le préparez pour l'avenir
- Dans la troisième itération, vous ajoutez de nouvelles fonctionnalités et en savoir plus.
- aller à 2
La source la plus intéressante que je connaisse à ce sujet est la partie D de Construction de logiciel orienté objet, 2e édition de Bertrand Meyer.
Partie D: Méthodologie orientée objet: bien appliquer la méthode
19: Méthodologie, 20: Modèle de conception: systèmes interactifs à panneaux multiples, 21: Étude de cas sur l'héritage: "annuler" dans un système interactif, 22: Comment trouver les classes , 23: Principes de conception des classes, 24: Bien utiliser l'héritage, 25: Techniques utiles, 26: Sens du style, 27 : Analyse orientée objet, 28: Le processus de construction du logiciel, 29: Enseigner la méthode
Fait intéressant, le chapitre 22. Comment trouver les classes est disponible en ligne.
C'est souvent répété mais tout à fait vrai: comprenez vos données.
Pour OOP, vos classes doivent décrire les informations essentielles et leur interaction.
Si vous avez un modèle mental qui décrit bien le comportement et la durée de vie des données, vous aurez un tour facile pour organiser vos cours.
Ceci est simplement une extension de: Sachez exactement ce que vous essayez de faire.
Essayez d'utiliser un développement axé sur le comportement. Il sera difficile de rompre avec vos vieilles habitudes, mais j’ai constaté que BDD est vraiment votre meilleur atout en matière de développement dans le monde réel.
Le problème avec les grands projets est que vous ne pouvez pas superviser toutes les interactions entre les composants. Il est donc important de réduire la complexité du projet. Les diagrammes de classe et de séquence sont trop détaillés pour cette phase de conception.
Essayez d’abord de penser à partir d’un niveau d’abstraction plus élevé. Pensez aux composants principaux et à leurs responsabilités (leur interface avec les autres composants), examinez certains modèles architecturaux comme source d'inspiration (non, pas de modèles de conception, ils sont d'un niveau trop bas! MVC et Multi-Tier sont des exemples de modèles architecturaux). Pour des projets raisonnablement volumineux, une telle vue devrait comporter environ 3 à 5 composants.
Ensuite seulement, vous zoomez sur un certain composant et essayez de le concevoir. Nous en sommes maintenant au niveau des modèles de conception et des diagrammes de classes. Essayez de vous concentrer sur cette partie du projet. Si vous estimez que vous devez ajouter une responsabilité à l’un des autres composants, ajoutez-la simplement à votre liste de documentation/tâches. Ne perdez pas de temps à penser aux implications à ce stade, elles changent beaucoup trop rapidement, passez en revue lorsque la conception est plus solide.
Vous n'avez pas besoin de concevoir complètement chaque composant à ce stade, bien qu'il soit probablement sage de disposer d'un morceau de code implémentant l'interface de composants non implémentés et générant des réponses simples mais utiles. De cette façon, vous pouvez commencer à développer (et concevoir) un composant à la fois et à le tester à un degré raisonnable.
Bien sûr, lorsque de nouveaux composants sont terminés, vous devez vérifier comment (et si) ils s'intègrent les uns aux autres avant de poursuivre.
En résumé: Prenez le principe OO et le masquage d’informations) et remontez à un autre niveau!
PS: Faites beaucoup de croquis en dessinant, c’est comme une véritable architecture!
PPS: Essayez d'aborder la question sous des angles différents, sortez des sentiers battus (bien que la boîte puisse être la voie à suivre), discuter avec des pairs peut être très utile pour cela… et vous avez quelque chose à dire pendant le déjeuner.
La technique que j'ai utilisée dans des projets réels avec un succès raisonnable est la Responsibility Driven Design, inspirée du livre de Wirfs-Brock.
Commencez par les user stories de haut niveau et, avec vos collègues, sur un tableau blanc, esquissez les interactions de haut niveau qu'elles impliquent. Cela vous donne une première idée de ce que sont les gros modules; et une ou deux itérations de jeu de cartes CRC de haut niveau devraient vous avoir stabilisé une liste des composants principaux, de ce qu’ils font et de la manière dont ils interagissent.
Ensuite, si l'une des responsabilités est grande ou complexe, affinez ces modules jusqu'à obtenir des éléments suffisamment petits et simples pour être des objets, en reproduisant les interactions à l'intérieur du module pour chacune des opérations principales identifiées par les interactions de niveau supérieur. .
Savoir quand s'arrêter est une question de jugement (qui ne vient que par l'expérience).
Modèles de conception
Modèles de création
Singleton - Assurez-vous qu'une seule instance d'une classe est créée et fournissez un point d'accès global à l'objet.
Factory (version simplifiée de la méthode Factory) - Crée des objets sans exposer la logique d'instanciation au client et fait référence au nouvel objet créé via une interface commune.
Méthode Factory - Définit une interface pour la création d'objets, mais laisse les sous-classes décider de la classe à instancier et fait référence au nouvel objet créé via une interface commune.
Abstract Factory - Offre l'interface pour créer une famille d'objets liés sans spécifier explicitement leurs classes.
Générateur - Définit une instance pour la création d'un objet, mais laisse les sous-classes décider de la classe à instancier et permet un contrôle plus précis du processus de construction.
Prototype - Spécifiez les types d'objets à créer à l'aide d'une instance prototype et créez de nouveaux objets en copiant ce prototype.
Modèles de conception comportementaux
Chaîne de responsabilités - Elle évite de joindre l'expéditeur d'une demande à son destinataire, donnant ainsi à d'autres objets la possibilité de traiter également la demande. - Les objets deviennent des parties d'une chaîne et la demande est envoyée d'un objet à l'autre à travers la chaîne jusqu'à ce qu'un des objets la gère.
Commande - Encapsuler une demande dans un objet, Permet le paramétrage de clients avec différentes demandes et Permet de sauvegarder les demandes dans une file d'attente.
Interprète - Dans une langue, définissez une représentation pour sa grammaire et un interprète qui utilise cette représentation pour interpréter des phrases dans la langue/mappez un domaine sur une langue, la langue sur une grammaire et la grammaire sur un modèle hiérarchique orienté objet
Itérateur - Fournit un moyen d'accéder aux éléments d'un objet agrégé de manière séquentielle sans exposer sa représentation sous-jacente.
Médiateur - Définissez un objet qui encapsule la manière dont un ensemble d'objets interagit. Le médiateur favorise le couplage lâche en empêchant les objets de se référer explicitement les uns aux autres, et vous permet de faire varier leur interaction indépendamment.
Observateur - Définissez une dépendance un à plusieurs entre les objets de sorte que lorsqu'un objet change d'état, tous ses dépendants soient notifiés et mis à jour automatiquement.
Stratégie - Définissez une famille d’algorithmes, encapsulez-les et rendez-les interchangeables. La stratégie permet à l’algorithme de varier indépendamment des clients qui l’utilisent.
Méthode de modèle - Définit le squelette d'un algorithme dans une opération, en reportant certaines étapes aux sous-classes/La méthode de modèle permet aux sous-classes de redéfinir certaines étapes d'un algorithme sans leur permettre de modifier la structure de l'algorithme.
Visiteur - Représente une opération à exécuter sur les éléments d'une structure d'objet/Visiteur vous permet de définir une nouvelle opération sans modifier les classes des éléments sur lesquels elle opère.
Objet nul - Fournit un objet comme substitut de l'absence d'un objet d'un type donné./Le modèle d'objet null fournit un comportement intelligent ne faisant rien, cachant les détails à ses collaborateurs.
Modèles de conception structurelle
Adaptateur - Convertissez l'interface d'une classe en une autre interface attendue par les clients./Adapter permet aux classes de travailler ensemble, ce qui ne pourrait pas autrement à cause d'interfaces incompatibles.
Pont - Composez les objets en arborescence pour représenter des hiérarchies entières./Composite permet aux clients de traiter des objets individuels et des compositions d'objets de manière uniforme.
Composite - Composez des objets en arborescence pour représenter des hiérarchies entières./Composite permet aux clients de traiter des objets individuels et des compositions d'objets de manière uniforme.
Décorateur - ajoute des responsabilités supplémentaires dynamiquement à un objet.
Flyweight - utilisez le partage pour prendre en charge un grand nombre d'objets ayant une partie de leur état interne en commun où l'autre partie de l'état peut varier.
Memento - Capture l'état interne d'un objet sans violer l'encapsulation et offrant ainsi un moyen de restaurer l'objet à l'état initial en cas de besoin.
Proxy - fournissez un "espace réservé" à un objet pour contrôler les références à celui-ci.
Je vous recommanderais d'utiliser BlueJ et aussi ActiveWriter pour apprendre et aussi pour développer une bonne compréhension des objets. Le livre recommandé est également une bonne ressource.
De Wikipedia :
BlueJ est un environnement de développement intégré pour le Java), développé principalement à des fins pédagogiques, mais également adapté au développement de logiciels à petite échelle.
De plus, il utilise UML et pour moi, c'était une bonne ressource pour comprendre plusieurs choses sur la modélisation des objets.
alt text http://www.ryanknu.com/ryan/bluej.png
ActiveWriter est un outil pour modéliser des entités et des relations, il génère également du code et est facile à modifier. Cela vous fera gagner du temps et pour le développement agile est très approprié.
(source: altinoren.com )
Je viens de citer http://www.fysh.org/~katie/computing/methodologies.txt
Et au cœur de RUP se trouve un petit espace où vous devez utiliser OO vos talents en matière de conception…. Si vous ne les avez pas, c’est comme avoir une méthodologie pour exécuter le 100 m.
"Étape 1: écrivez sur le fait de courir très vite. Étape 2: Planifiez le circuit. Étape 3: achetez un short en lycra très serré. Étape 4: courez vraiment, vraiment, très vite. Étape 5: traversez la ligne en premier "
C'est l'étape 4 qui est la plus difficile. Mais si vous mettez beaucoup d'emphase sur les positions 1, 2, 3 et 5, il est possible que personne ne le remarque et que vous pourriez probablement gagner beaucoup d'argent en vendant la méthodologie à des athlètes qui pensent qu'il existe un "secret" pour être un 100 m coureur
Tout d’abord, le design doit venir de votre âme. Vous devez le ressentir sous toutes vos fibres. Je marche habituellement pendant deux ou trois mois avant de commencer à faire quoi que ce soit, juste marcher dans les rues (vraiment). Et en réfléchissant. La marche est une bonne méditation, vous savez. Cela vous permet donc de bien vous concentrer.
Deuxièmement, utilisez OOP et les classes uniquement lorsqu'une hiérarchie d'objets naturelle existe. Ne la "vissez" artificiellement à cette structure. Si aucune hiérarchie stricte n'existe (comme dans la plupart des applications métier) - allez pour des objets procéduraux/fonctionnels, ou du moins, utilisez uniquement des objets comme conteneurs de données avec des accesseurs isolés.
Et le dernier - essayez de lire ceci: L’algorithme de la pensée créatrice
Vous avez posé la question que beaucoup d'auteurs utilisent pour écrire un livre. Il existe un certain nombre de méthodologies et vous devriez en choisir une qui vous semble "la plus jolie".
Je peux recommander le livre "Domain Driven Design" de Eric Evans. Consultez également le site dddcommunity.org .
Je pense que la réponse ici devrait être très différente en fonction de l'expérience réelle du gars qui pose la question.
Si vous n’avez qu’une ou deux années d’expérience professionnelle, vous devez vous rendre au point: comment en arrivez-vous au point où vous connaissez réellement vos données et comprenez exactement ce que vous essayez de faire?
Oui, si vous travaillez dans le monde réel depuis au moins 5 ans, vous aurez le choix entre l’un des nombreux modèles ou techniques de processus de développement logiciel.
Mais vous ne gagnez pas d'expérience en lisant des livres Vous devriez apprendre en travaillant dans un bon groupe sous un bon leadership.
Si ce n'est pas possible, vous devriez simplement le faire vous-même. Commencez par itérer en codant un code probablement très méchant, en apprenant vos erreurs, en le vidant, en codant un code de meilleure qualité, etc.
Vous en apprendrez beaucoup sur votre base de code. Les outils sont des outils, ils ne vous apprendront rien.
Si vous avez une expertise de domaine sur le projet sur lequel vous allez travailler, comme par exemple le secteur bancaire. Il est facile de structurer vos objets et vous savez comment ces améliorations se produisent tous les deux jours.
Si vous ne possédez pas cette expertise, travaillez avec une personne qui possède cette expertise et convertissez ces idées en détails techniques.
Si vous ne savez pas comment structurer la conception de votre projet. Suivez aveuglément le livre "programmeur pragmatique". J'étais dans la même situation avant, essayez de lire un chapitre de ce livre. vous verrez la différence, cela changera votre façon de penser en tant que développeur de logiciels.
J'utilise Test-Driven Design (TDD). Écrire le premier test vous aide réellement à créer une conception propre et correcte. Voir http://en.wikipedia.org/wiki/Test-driven_development .
- étudier et maîtriser les modèles de conception.
- Ensuite, en savoir plus sur la conception axée sur le domaine
- Après cela, apprendre la collecte des exigences
J'ai suivi un cours OOD quelques semestres en arrière et j'ai beaucoup appris de ce cours; comme l'écriture UML et la traduction de documents d'exigences en objets et en classes. Nous avons aussi appris les diagrammes de séquence, mais d’une manière ou d’une autre, j’ai manqué la conférence ou quelque chose du genre, ils ne sont pas restés fidèles à moi.
Vous connaissez l'étape 3. Vous devez la maîtriser. Je veux dire, avec beaucoup de pratique pour le faire devenir votre seconde nature. C'est parce que la méthode que vous apprenez est tout simplement opposée à celle que nous utilisions auparavant. Donc, vous devez vraiment le maîtriser. Sinon, vous retrouverez toujours votre façon de faire originale. Cela ressemble en quelque sorte au processus piloté par les tests, dans lequel de nombreux développeurs Java abandonnent après quelques essais. À moins qu'ils le maîtrisent complètement, sinon ce n'est qu'un fardeau pour eux
Rédigez des cas d'utilisation, en particulier pour les cours alternatifs. Les cours alternatifs occupent plus de 50% de notre temps de développement. Normalement, lorsque votre PM vous attribue une tâche, par exemple, crée un système de connexion, il pensera que c'est simple, vous pouvez prendre 1 jour pour la terminer. Mais il ne tient jamais compte de ce que vous devez considérer, 1. Que se passe-t-il si l'utilisateur saisit un mauvais mot de passe, 2. Que se passe-t-il si l'utilisateur saisit un mauvais mot de passe 3 fois, 3. Que se passe-t-il si l'utilisateur ne tape pas le nom d'utilisateur, etc. Vous devez les énumérer et les montrer à votre premier ministre, lui demander de reporter la date limite.
Je crains que ce ne soit pas une réponse les gens aiment entendre. Quoi qu'il en soit, laissez-moi exprimer mon opinion.
La POO devrait être considérée comme l'un des paradigmes et non comme le paradigme supérieur. OOP est utile pour résoudre certains types de problèmes, comme le développement d’une bibliothèque d’interface graphique. Il s’intègre également dans le style de développement de logiciels généralement suivi par les grandes entreprises de logiciels - une équipe d'élite composée de designers ou architectes définit la conception logicielle dans des diagrammes UML ou un autre support similaire, ainsi qu'une équipe moins éclairée de développeurs traduit cette conception en code source. OOP n'offre que peu d'avantages si vous travaillez seul ou avec une petite équipe de programmeurs extrêmement talentueux. Ensuite, il est préférable d'utiliser un langage prenant en charge plusieurs paradigmes et permettant de créer rapidement un prototype. Python , Ruby, LISP/Scheme etc sont de bons choix. Le prototype est votre conception. Ensuite vous améliorez cela. Utilisez le paradigme qui vous convient le mieux pour résoudre le problème actuel. Si nécessaire, optimisez les points chauds avec des extensions écrites en C ou autre. En utilisant l’un de ces langages, vous obtenez également extensibilité gratuitement, pas seulement chez le programmeur niveau mais aussi au niveau utilisateur. Des langues telles que LISP peuvent générer et exécuter du code de manière dynamique, ce qui signifie que vos utilisateurs peuvent étendre l'application en écrivant de petits extraits de code, dans la langue dans laquelle le logiciel est codé! Ou si vous choisissez d'écrire le programme en C ou C++, envisagez d'incorporer un interprète pour un petit langage comme Lua. Exposer les fonctionnalités en tant que plugins écrit dans cette langue.
Je pense que la plupart du temps OOP et OOD créent des logiciels victimes de sur-conception.
Pour résumer, ma méthode préférée pour écrire un logiciel est la suivante:
- Utilisez un langage dynamique.
- Écrivez le dessin (prototype) dans cette langue même.
- Si nécessaire, optimisez certaines zones en utilisant C/C++.
- Fournissez une extensibilité par le biais de l'interprète du langage d'implémentation lui-même.
La dernière fonctionnalité permet au logiciel de s’adapter facilement aux besoins spécifiques de l’utilisateur (y compris moi-même!).
Apprenez les modèles de conception . C’est ma révolution personnelle depuis deux ans en ce qui concerne la POO. Obtenez un livre. Je vous recommanderais celui-ci:
Il est en Java mais il peut être extensible à n’importe quel langage.
Honnêtement, un bon pas en arrière consisterait à regarder les organigrammes et les séquences de séquences. Il existe une tonne de bons sites qui vous montrent comment le faire. Je trouve cela très utile d’expliquer comment je veux diviser un programme en classes, car je sais exactement ce dont le programme a besoin, entré, calculé et sorti, et chaque étape peut être décomposée en une partie du programme.
Comme indiqué dans la rubrique Quel est le flux de travail que vous suivez pour concevoir le logiciel que vous êtes sur le point d’écrire?
Au cours de mes aventures dans la conception de structures de classes, j’ai remarqué qu’il était très utile de commencer à écrire du pseudo-code. Cela signifie que je commence par "écrire" des fragments généraux du code d’application au plus haut niveau, que je joue avec et que je découvre les éléments qui apparaissent - en fait, les éléments que j’aimerais, en tant que programmeur, utiliser. C’est un très bon point de départ pour la conception de la structure générale des modules et de leurs interactions. Après quelques itérations, l'ensemble de la structure commence à ressembler davantage à un système complet de classes. C’est un moyen très flexible de concevoir des parties de code. Vous pouvez appeler cela une conception orientée programmeur.
Une technique utile consiste à associer la description de votre problème unique à quelque chose que vous pouvez trouver dans le monde réel. Par exemple, vous modélisez un système de santé complexe qui prendra le monde d'assaut. Existe-t-il des exemples auxquels vous pouvez facilement faire appel pour modéliser cela?
En effet. Observez le fonctionnement de la pharmacie ou de la chambre du médecin.
Réduisez votre problème de domaine à quelque chose de compréhensible pour vous; quelque chose auquel vous pouvez rapporter.
Ensuite, une fois que les "acteurs" du domaine commencent à apparaître comme une évidence, et que vous commencez à modéliser votre code, optez pour une approche de modélisation "fournisseur-consommateur", c’est-à-dire que votre code est le "fournisseur" du modèle, et vous êtes le "consommateur".
Relier au domaine et le comprendre à un niveau élevé est un élément clé de toute conception.