Comment concevez-vous des projets orientés objet? [fermé]

Je travaille sur un grand projet (pour moi) qui aura de nombreuses classes et devra être extensible, mais je ne sais pas comment planifier mon programme et comment les classes doivent interagir.

J'ai suivi un cours OOD il y a quelques semestres et j'en ai beaucoup appris; comme l'écriture d'UML et la traduction de documents d'exigences en objets et en classes. Nous avons aussi appris des diagrammes de séquence mais d'une manière ou d'une autre j'ai raté la conférence ou quelque chose du genre, ils ne m'ont pas vraiment collé.

Avec des projets précédents, j'ai essayé d'utiliser des méthodes que j'ai apprises du cours, mais je me retrouve généralement avec du code qui dès que je peux dire "oui, ça ressemble à ce que j'avais en tête", je n'ai aucune envie de fouiller dans la boue pour ajouter nouvelles fonctionnalités.

J'ai une copie du Code Complete de Steve McConnell que j'entends continuellement étonner ici et ailleurs. J'ai lu le chapitre sur le design et ne semble pas avoir fourni les informations que je recherche. Je sais qu'il dit que ce n'est pas un processus coupé et séché, qu'il est principalement basé sur l'heuristique, 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 la programmation) 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 les unes avec les autres ?

Plus précisément, je suis intéressé par 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 de près le produit final?

Les étapes que j'utilise pour la conception initiale (accéder à un diagramme de classes) sont les suivantes:

1. Rassemblement des exigences. Parlez au client et factorisez les cas d'utilisation pour définir les fonctionnalités que le logiciel devrait avoir.

2. Composez un récit des cas d'utilisation individuels.

3. Parcourez le récit et mettez en évidence les noms (personne, lieu, chose), en tant que classes candidates et les verbes (actions), en tant que méthodes / comportements.

4. Jetez les noms en double et éliminez les fonctionnalités courantes.

5. 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 c'est GRATUIT. Eclipse (un IDE Java open source), a également un cadre de modélisation, mais je n'ai aucune expérience avec lui. Vous pouvez également essayer ArgoUML, un outil open source.

6. Appliquez les principes OOD pour organiser vos classes (factoriser les fonctionnalités communes, construire des hiérarchies, etc.)

Ajoutant à ce que Scott Davies avait à dire:

1. Assurez-vous absolument de savoir en quoi consiste votre programme avant de commencer. Quel est ton programme? Que ne fera-t-il pas ? Quel problème essaie-t-il de résoudre?

2. Votre premier ensemble de cas d'utilisation ne devrait pas être une liste de blanchisserie de tout ce que le programme finira par faire. Commencez avec le plus petit ensemble de cas d'utilisation que vous pouvez trouver qui capture toujours l'essence de ce à quoi sert votre programme. Pour ce site Web, par exemple, les principaux cas d'utilisation peuvent être la connexion , la pose d'une question , la réponse à une question et l' affichage des questions et des réponses . Rien sur la réputation, le vote ou le wiki de la communauté, juste l'essence brute de ce que vous visez.

3. Lorsque vous proposez des classes potentielles, ne pensez pas à elles uniquement en termes de nom qu'elles représentent, mais de responsabilités. J'ai trouvé que c'était la plus grande aide pour comprendre comment les classes étaient liées les unes aux autres pendant l'exécution du programme. Il est facile de trouver des relations comme «un chien est un animal» ou «un chiot a une mère». Il est généralement plus difficile de trouver des 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 précisé le travail de chaque classe.

4. Une fois que vous avez cet ensemble minimal de cas d'utilisation et d'objets, commencez à coder. Obtenez quelque chose qui fonctionne réellement dès que possible, même s'il ne fait pas grand-chose et ressemble probablement à de la merde. C'est un point de départ et vous obligera à répondre à des questions que vous pourriez passer sous silence sur le papier.

5. Maintenant, revenez en arrière et choisissez plus de cas d'utilisation, écrivez comment ils fonctionneront, modifiez votre modèle de classe et écrivez plus de code. Tout comme votre première coupe, prenez le moins possible à la fois tout en ajoutant quelque chose de significatif. Rincez et répétez.

Juste mes deux cents. J'espère que c'est utile.

Quand j'en ai eu 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-êtrefutures). Je n'écris pas de documents de conception, mais si je dois coordonner plusieurs personnes, une esquisse approximative de la procédure est bien sûr nécessaire, ainsi qu'une analyse des dépendances et une estimation du temps nécessaire. Essayez de garder cette phase au minimum si, comme moi, vous préférez une méthode plus agile. Il y a des cas où une phase de conception forte est nécessaire, en particulier lorsque tout est connu et vrai sur la logique de votre programme, et si vous prévoyez d'avoir beaucoup d'interactions entre les fonctionnalités de votre code. Dans ce cas, les cas d'utilisation ou les user stories constituent une bonne idée de haut niveau, en particulier pour les applications GUI. Pour les applications en ligne de commande, et en particulier les bibliothèques, essayez d'écrire des "histoires de programme" dans lesquelles vous codez par rapport à la bibliothèque que vous devez développer et vérifiez à quoi elle ressemble.

Après cette première itération, vous aurez une meilleure compréhension de la façon dont les choses interagissent, obtenu les détails et les points difficiles, résolu les problèmes avec un patch de ruban adhésif giflé. Vous êtes prêt à utiliser cette expérience pour améliorer, nettoyer, peaufiner, diviser ce qui était trop grand, fusionner ce qui était trop fragmenté, définir et utiliser des modèles de conception, analyser les goulots d'étranglement des performances et les 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 itération, vous aurez un petit bijou, bien testé, bien documenté et bien conçu. Vous avez maintenant à la fois l'expérience et le code pour effectuer la troisième itération, étendre. Vous ajouterez de nouvelles fonctionnalités et des cas d'utilisation pour améliorer votre application. Vous trouverez des points difficiles et vous finirez par entrer dans une quatrième itération qui est analogue à la seconde. Rincez et répétez.

Ceci est mon approche générale de la conception de logiciels. Il est similaire à la conception en spirale, avec des itérations courtes et de trois mois et des éléments de développement Agile, qui vous permet d'apprendre les problèmes et de connaître votre logiciel et son domaine d'application. Bien sûr, c'est une question d'évolutivité, donc si l'application est si grande pour impliquer 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, divide et impera .

Donc, résumant:

1. Dans la première itération, vous en avez un avant-goût et apprenez
2. Dans l'itération deux, vous nettoyez votre produit et le préparez pour l'avenir
3. Dans l'itération trois, vous ajoutez de nouvelles fonctionnalités et en savoir plus
4. goto 2

La source la plus intéressante que je connaisse à ce sujet est la partie D de Object Oriented Software Construction, 2nd Edition de Bertrand Meyer.

Partie D: Méthodologie orientée objet: bien appliquer la méthode

19: Sur la méthodologie, 20: Modèle de conception: systèmes interactifs multi-panels, 21: Étude de cas d'héritage: "annuler" dans un système interactif, 22: Comment trouver les classes , 23: Principes de conception de classe, 24: Bien utiliser l'héritage , 25: Techniques utiles, 26: Un sens du style, 27: Analyse orientée objet, 28: Le processus de construction de logiciels, 29: Enseignement de la méthode

Fait intéressant, le chapitre 22. Comment trouver les cours est disponible en ligne.

C'est souvent répété mais tout à fait vrai - comprenez vos données.

Pour la POO, vos classes doivent décrire des informations saillantes et comment elles interagissent.

Si vous avez un modèle mental qui décrit bien le comportement et la durée de vie des données, vous pourrez facilement organiser vos cours.

Il s'agit simplement d'une extension de: Sachez exactement ce que vous essayez de faire.

Essayez d'utiliser le développement axé sur le comportement. Il sera difficile de briser vos anciennes habitudes, mais j'ai trouvé que BDD est vraiment votre meilleur pari quand il s'agit de se développer dans le monde réel.

http://behaviour-driven.org/

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 classes et de séquences 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 principaux composants et à leurs responsabilités (leur interface avec d'autres composants), regardez quelques modèles architecturaux pour vous inspirer (non, pas des modèles de conception, ce sont des niveaux trop bas! MVC et Multi-Tier sont des exemples de modèles architecturaux). Pour les projets assez importants, une telle vue devrait avoir environ 3 à 5 composants.

C'est seulement alors que vous zoomez sur un certain composant et essayez de le concevoir. Nous 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 trouvez que vous devez ajouter une responsabilité à l'un des autres composants, ajoutez-la simplement à votre documentation / liste de tâches. Ne perdez pas de temps à penser aux implications à ce stade, elles changent beaucoup trop rapidement, vérifiez quand la conception est plus solide.

Vous n'avez pas besoin de concevoir complètement chaque composant à ce stade, bien qu'il soit probablement judicieux d'avoir un morceau de code qui implémente l'interface des composants non implémentés et génère des réponses simples mais utiles. De cette façon, vous pouvez démarrer le développement (et concevoir) un composant à la fois et le tester à un degré raisonnable.

Bien sûr, lorsque de nouveaux composants sont terminés, vous devez tester comment (et si) ils s'intègrent les uns aux autres avant de continuer.

En bref: prenez l'OO et le principe de masquage de l'information et remontez-le d'un autre niveau!

PS: Faites beaucoup de croquis pendant la conception, c'est comme une vraie architecture!

PPS: Essayez d'aborder la question sous différents angles, 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 à discuter pendant le déjeuner.

La technique que j'ai utilisée dans des projets réels avec un succès raisonnable est la conception axée sur la responsabilité, inspirée du livre de Wirfs-Brock.

Commencez par les histoires d'utilisateurs 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 carte CRC de haut niveau, vous devriez avoir stabilisé une liste des principaux composants, ce qu'ils font et comment ils interagissent.

Ensuite, si l'une des responsabilités est grande ou complexe, affinez ces modules jusqu'à ce que vous ayez des choses suffisamment petites et simples pour être des objets, en jouant les interactions à l'intérieur du module pour chacune des principales opérations identifiées par les interactions de niveau supérieur. .

Savoir quand s'arrêter est une question de jugement (qui ne vient qu'avec l'expérience).

Modèles de conception

Modèles de conception créatifs

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 à l'objet nouvellement créé via une interface commune.

Méthode d'usine: définit une interface pour créer des objets, mais laisse les sous-classes décider de la classe à instancier et fait référence à l'objet nouvellement 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.

Builder - Définit une instance pour créer un objet mais laisse les sous-classes décider de la classe à instancier et permet un contrôle plus fin du processus de construction.

Prototype - Spécifiez les types d'objets à créer à l'aide d'une instance prototypique et créez de nouveaux objets en copiant ce prototype.

Modèles de conception comportementale

Chaîne de responsabilité - Il évite d'attacher l'expéditeur d'une demande à son destinataire, donnant ainsi à d'autres objets la possibilité de gérer la demande également. - Les objets deviennent des parties d'une chaîne et la demande est envoyée d'un objet à un 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 des clients avec différentes demandes et Permet d'enregistrer les demandes dans une file d'attente.

Interprète - Étant donné une langue, définissez une représentation de sa grammaire avec un interprète qui utilise la représentation pour interpréter des phrases dans la langue / Mapper un domaine à une langue, la langue à une grammaire et la grammaire à une conception hiérarchique orientée objet

Itérateur - Fournit un moyen d'accéder séquentiellement aux éléments d'un objet agrégé sans exposer sa représentation sous-jacente.

Médiateur - Définissez un objet qui résume la façon 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 il vous permet de varier leur interaction indépendamment.

Observateur - Définissez une dépendance un-à-plusieurs entre les objets afin que lorsqu'un objet change d'état, toutes ses dépendances soient notifiées et mises à jour automatiquement.

Stratégie - Définissez une famille d'algorithmes, encapsulez chacun d'eux 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éfinissez 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 les laisser modifier la structure de l'algorithme.

Visiteur - Représente une opération à effectuer sur les éléments d'une structure d'objet / Visiteur vous permet de définir une nouvelle opération sans changer les classes des éléments sur lesquels elle opère.

Null Object - Fournit un objet comme substitut pour l'absence d'un objet d'un type donné. / Le modèle d'objet nul fournit un comportement intelligent de ne rien faire, 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 être le cas à cause d'interfaces incompatibles.

Pont - Composez des objets en arborescences pour représenter des hiérarchies partielles. / Composite permet aux clients de traiter les objets individuels et les compositions d'objets de manière uniforme.

Composite - Composez des objets en arborescences pour représenter des hiérarchies partielles. / Composite permet aux clients de traiter les objets individuels et les compositions d'objets de manière uniforme.

Décorateur - ajoutez dynamiquement des responsabilités supplémentaires à un objet.

Flyweight - utilisez le partage pour prendre en charge un grand nombre d'objets qui ont en commun une partie de leur état interne où l'autre partie de l'état peut varier.

Memento - capturer l'état interne d'un objet sans violer l'encapsulation et fournir ainsi un moyen de restaurer l'objet dans son état initial en cas de besoin.

Proxy - fournit un «espace réservé» à un objet pour contrôler ses références.

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 Wikipédia :

BlueJ est un environnement de développement intégré pour le langage de programmation Java, développé principalement à des fins éducatives, 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 d'objets.

texte alternatif 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 à effectuer des modifications. Cela vous fera gagner du temps et pour un développement agile est très approprié.

_{(source: altinoren.com )}

Tout d'abord - le design doit venir de votre âme. Vous devez le ressentir par chacune de vos fibres. Je le descends habituellement pendant deux ou trois mois avant de commencer quoi que ce soit, je marche dans les rues (vraiment). Et penser. La marche est une bonne méditation, vous savez. Cela vous permet donc de bien vous concentrer.

Deuxièmement - utilisez la POO et les classes uniquement lorsqu'il existe une hiérarchie d'objets naturels. Ne le vissez pas artificiellement. S'il n'existe pas de hiérarchie stricte (comme dans la plupart des applications métier), optez pour les procédures / fonctions ou, au moins, utilisez les objets uniquement comme conteneurs de données avec des accesseurs isolés.

Et le dernier - essayez de lire ceci: L'algorithme de la pensée créative

Je cite simplement http://www.fysh.org/~katie/computing/methodologies.txt

Et au cœur de RUP se trouve un petit domaine où vous devez utiliser les talents de conception OO ... si vous ne les avez pas, c'est comme avoir une méthodologie pour courir le 100m.

"Étape 1: écrivez sur la course à pied très vite. Étape 2: allez dessiner un plan de l'hippodrome. Étape 3: allez acheter des shorts en lycra vraiment serrés. Étape 4: courez vraiment, vraiment, vraiment très vite. Étape 5: croisez d'abord "

C'est cette étape 4 qui est la plus difficile. Mais si vous mettez beaucoup d'accent sur 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 y a un "secret" au 100m. coureur

Vous avez posé une 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" par 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 suivant: comment arrivez-vous au point où vous connaissez vraiment vos données et comprenez exactement ce que vous essayez de faire?

Oui, si vous travaillez dans le monde réel depuis plus de 5 ans, vous pouvez choisir entre l'un des nombreux modèles ou techniques de processus de développement logiciel.

Mais vous n'avez pas d'expérience en lisant uniquement des livres. Vous devez apprendre en travaillant dans un bon groupe sous un bon leadership.

Si ce n'est pas possible, vous devez le faire vous-même. Commencez l'itération en codant un morceau de code probablement très méchant, en apprenant vos erreurs, en vidant tout, en codant un meilleur et ainsi de suite.

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, vous allez travailler comme par exemple sur la banque. Il est facile de structurer vos objets et vous savez comment ces améliorations se produisent tous les deux jours.

Si vous n'avez pas cette expertise, travaillez avec quelqu'un qui a 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.

1. étudier et maîtriser les modèles de conception.
2. Découvrez ensuite la conception pilotée par domaine
3. Après cela, découvrez la collecte des exigences

J'ai suivi un cours OOD il y a quelques semestres et j'en ai beaucoup appris; comme l'écriture d'UML et la traduction de documents d'exigences en objets et en classes. Nous avons aussi appris des diagrammes de séquence mais d'une manière ou d'une autre j'ai raté la conférence ou quelque chose du genre, ils ne m'ont pas vraiment collé.

4. Vous connaissez l'étape 3. Vous devez la maîtriser. Je veux dire, via beaucoup de pratique pour en faire votre seconde nature. C'est parce que la méthode que vous apprenez est tout simplement contraire à ce que nous avions auparavant. Vous devez donc vraiment le maîtriser. Sinon, vous vous retrouverez toujours à revenir à votre façon originale de faire les choses. C'est en quelque sorte comme Test Driven Process, où beaucoup de développeurs java abandonnent après quelques essais. A moins qu'ils ne le maîtrisent pleinement, sinon c'est juste un fardeau pour eux

5. Écrivez des cas d'utilisation, en particulier pour un cours alternatif. 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éer un système de connexion, il pensera que c'est simple, vous pouvez prendre 1 jour pour le terminer. Mais il ne prend jamais en compte ce que vous devez considérer, 1. que faire 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 son nom d'utilisateur, etc. Vous devez les répertorier et les montrer à votre PM, lui demander de reporter la date limite.

Je crains que ce ne soit pas une réponse que les gens aiment entendre . Quoi qu'il en soit, permettez-moi d'exprimer mon opinion.

La POO doit être considérée comme l'un des paradigmes et non comme un paradigme supérieur. La POO est bonne pour résoudre certains types de problèmes, comme le développement d'une bibliothèque GUI. Il s'inscrit également dans le style de développement logiciel généralement suivi par les grandes sociétés de logiciels - une équipe d'élite de concepteurs ou d' architectes définit la conception du logiciel dans des diagrammes UML ou un autre support similaire et une équipe de développeurs moins éclairéetraduire cette conception en code source. La POO offre peu d'avantages si vous travaillez seul ou avec une petite équipe de programmeurs très talentueux. Ensuite, il est préférable d'utiliser un langage qui prend en charge plusieurs paradigmes et vous aidera à trouver 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 le mieux adapté pour résoudre le problème en question. Si nécessaire, optimisez les points chauds avec des extensions écrites en C ou dans un autre langage système. En utilisant l'une de ces langues, vous bénéficiez également de l' extensibilitégratuitement, non seulement au niveau programmeur mais aussi au niveau utilisateur. Des langages comme Lisp peuvent générer et exécuter dynamiquement du code, ce qui signifie que vos utilisateurs peuvent étendre l'application en écrivant de petits extraits de code, dans la langue dans laquelle le logiciel lui-même est codé! Ou si vous choisissez d'écrire le programme en C ou C ++, envisagez d'incorporer un interpréteur pour un petit langage comme Lua. Exposez les fonctionnalités sous forme de plugins écrits dans cette langue.

Je pense que, la plupart du temps, OOP et OOD créent des logiciels qui sont victimes d'une conception excessive.

Pour résumer, ma façon préférée d'écrire un logiciel est:

1. Utilisez un langage dynamique.
2. Écrivez la conception (prototype) dans cette langue elle-même.
3. Si nécessaire, optimisez certaines zones à l'aide de C / C ++.
4. Fournir une extensibilité via l'interpréteur du langage d'implémentation lui-même.

La dernière fonctionnalité permet au logiciel de s'adapter facilement aux besoins spécifiques des utilisateurs (y compris moi-même!).

J'utilise la conception pilotée par les tests (TDD). Écrire d'abord le test vous aide en fait à vous conduire vers un design propre et correct. Voir http://en.wikipedia.org/wiki/Test-driven_development .

Apprenez les modèles de conception . Cela a été ma révolution personnelle au cours des deux dernières années en ce qui concerne la POO. Obtenez un livre. Je vous recommanderais celui-ci:

Modèles de conception Head First

Il est en Java mais il peut être extensible à n'importe quel langage.

Honnêtement, une bonne étape serait de revenir en arrière et d'examiner le diagramme de flux et le diagramme de séquence. Il y a une tonne de bons sites qui vous montrent comment le faire. Je trouve que cela est inestimable lorsque je regarde comment je veux décomposer un programme en classes car je sais exactement ce dont le programme a besoin en entrée, en calcul et en sortie et chaque étape peut être décomposée en une partie du programme.

Comme indiqué dans Quel est le flux de travail que vous suivez pour concevoir le logiciel que vous vous apprêtez à écrire?

Une technique utile consiste à relier votre description de problème unique à quelque chose que vous pouvez trouver dans le monde réel. Par exemple, vous modélisez un système de soins de santé complexe qui va prendre le monde d'assaut. Y a-t-il des exemples que vous pouvez facilement invoquer pour modéliser cela?

En effet. Observez le fonctionnement de la pharmacie secondaire ou la chambre du médecin.

Apportez votre problème de domaine à quelque chose de compréhensible pour vous; quelque chose auquel vous pouvez vous rapporter.

Ensuite, une fois que les «acteurs» du domaine commencent à apparaître comme évidents 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.

Au cours de mes aventures de conception de structures de classe, j'ai remarqué qu'il est très utile de commencer par écrire du pseudo-code. Cela signifie: je commence par «écrire» quelques fragments généraux du code de l'application au plus haut niveau, je joue avec, et 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 concevoir la structure générale des modules et leurs interactions. Après quelques itérations, la structure entière commence à ressembler davantage à un système complet de classes. C'est une manière très flexible de concevoir des parties de code. Vous pouvez l'appeler une conception orientée programmeur.