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

231

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?

Victor
la source
2
Je pensais que Code Complete était assez utile à ce sujet - en particulier les chapitres 5.3 et 5.4 (qui ont quelques suggestions plus concrètes), et l'ensemble du chapitre 6. Cependant, je n'ai pas fait de conception de code pour un grand projet.
Paul D.Waite
1
Je peux recommander de suivre un cours sur la conception orientée objet en Java. Il y en a un excellent publié sur UDEMY udemy.com/mastering-object-oriented-design-in-java/… . Je pense que cela peut certainement vous aider. Une autre grande ressource est d'essayer le problème orienté objet ATM. Vous pouvez google ça.
Horse Voice
Je recommanderais à tout le monde de revenir sur cette question lors de la conception. Il y a beaucoup de contenu ici. De cette façon, vous pouvez parcourir votre mémoire pendant que vous effectuez la conception réelle.
Kevin Wheeler du

Réponses:

199

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.)

Scott Davies
la source
6
Il s'agit en effet d'une technique utile, surtout lorsque vous ne disposez pas d'une véritable poignée sur le domaine problématique. Cependant, il produit rarement une architecture optimale.
NomeN
1
Je peux recommander de suivre un cours sur la conception orientée objet en Java. Il y en a un excellent publié sur UDEMY udemy.com/mastering-object-oriented-design-in-java/…. Je pense que cela peut certainement vous aider. Une autre grande ressource est d'essayer le problème orienté objet ATM. Vous pouvez google ça.
Horse Voice
1
Où apprenez-vous cela? Pourriez-vous s'il vous plaît fournir la source de cela?
Kanagavelu Sugumar
68

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.

Darryl
la source
19

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
Stefano Borini
la source
16

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.

Daniel Daranas
la source
12

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.

Dave Gamble
la source
12
Le comportement des objets est plus important que les données. C'est le résultat direct de l'encapsulation: le cœur de la programmation orientée objet. L'exposition aux données (à partir de langages comme C et Pascal) conduit à des systèmes difficiles à maintenir (à améliorer et à déboguer) simplement parce que vous ne savez jamais à quel autre endroit du système les données sont modifiées. La POO ne concerne pas les données; La POO concerne le comportement. C'est une distinction importante.
Dave Jarvis
C'est une distinction importante, mais cela ne signifie pas que le comportement est plus important que les données.
johnny
Pour OOD, je commence généralement par la conception du modèle après avoir clarifié les exigences, ce qui me donne une idée de base sur la façon dont les entités doivent être organisées et sur la relation entre elles. Dans le même temps, j'ai une idée de base sur les opérations qui pourraient se produire dans chaque entité. Après une ébauche d'image sur les modèles, nous pouvons examiner les exigences et vérifier si nous manquons quelque chose. Et puis il sera plus facile de revenir au niveau de la classe et au niveau du contrôleur.
Joshua
10

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/

Eric le rouge
la source
1
+1 L'utilisation du développement basé sur le test / comportement / domaine vous permet de créer des classes au fur et à mesure, vous éviterez ainsi la méthodologie problématique de conception en cascade.
Halvard
8

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.

NomeN
la source
7

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).

Steve Gilham
la source
+1 pour le tableau blanc, chose exceptionnelle: DI résout 80% des problèmes assis devant le tableau blanc, juste en le regardant et en pensant "ce qui serait le meilleur?"
usoban
7

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.

Sauron
la source
2
Les modèles sont utiles pour certaines personnes. Je pense qu'il faut une expérience considérable pour voir les modèles dans les exigences. Et vous devrez probablement les documenter. Je suis enclin à penser que les modèles ne sont rien d'autre que des bibliothèques de composants abstraits.
CyberFonic
5

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 :

texte alternatif

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é.

texte alternatif
(source: altinoren.com )

Nelson Miranda
la source
1
j'ai utilisé le bleu J ... c'est certainement utile mais comment cela m'aide-t-il à concevoir des classes et leurs relations?
Victor
1
Je pense que cela m'a permis de voir le tableau complet sur la façon d'identifier les classes et de les relier visuellement, dans mes premières étapes, j'ai expérimenté comment était la représentation du code des objets et comment comprendre pour penser dans les objets. Je me souviens quand j'ai consacré du temps à comprendre le "est un" et "a un" et l'UML était une excellente aide. Depuis lors, j'utilise ces outils visuels pour concevoir mes objets et quand j'ai découvert ActiveWriter, j'étais très heureux car BlueJ n'a pas de génération de code et cet outil en a, juste pour renforcer mon argument, je pense que visuellement, vous avez une approche plus large d'une solution.
Nelson Miranda
4

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

Thevs
la source
4

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

Martin
la source
4

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 .

zendar
la source
3

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.

IlDan
la source
3

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.

Lien brisé
la source
2
  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é.

  1. 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

  2. É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.

janetsmith
la source
2

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!).

Vijay Mathew
la source
C'est à peine conseiller sur la façon de concevoir
NomeN
2
J'utilise une approche similaire. Pour éviter d'être submergé par la complexité, commencez par une vue en hélicoptère. J'aime un croquis avec 8-20 fonctions. Si je commence à en obtenir plus, je regarde comment partitionner en sous-systèmes. Une fois que j'ai cette vue de haut niveau, je décompose chaque fonction en 8-20 sous-fonctions, etc. En regardant ce que ces fonctions manipulent, j'obtiens les classes de niveau supérieur. C'est à ce moment que je commence à disposer le système squelettique en Python, alias pseudo code exécutable. Avec les blocs de commentaires, c'est ma «spécification exécutable» qui est ensuite progressivement affinée.
CyberFonic
2

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 .

David Allen
la source
2
TDD permet de visualiser initialement votre système comme une boîte noire avec ses échantillons d'entrée et de sortie. Mais en soi, cela ne vous aide pas à concevoir le système. Je voulais dire que pour le test unitaire, vous devez d'abord trouver l'interface de classe à tester
Vicente Bolea
2

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.

David Espart
la source
1

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.

user133018
la source
1
J'aime les organigrammes lorsque je suis bloqué sur un problème. Cela m'aide parfois à penser le problème d'une manière différente.
user133018
Au lieu de ou aussi bien que des organigrammes, les "diagrammes de flux de données" (DFD) sont beaucoup plus de haut niveau: ils ressemblent plus à un diagramme de déploiement UML, et conviennent pour obtenir un aperçu des fonctionnalités du système (c.-à-d. sortie de données, stockage de données interne et externe et traitement des données) et architecture. Les organigrammes ont (à mon humble avis) une portée plus proche de la modélisation d'une fonction unique avec des instructions if-then-else.
ChrisW
Ouais, j'utilise les deux la plupart du temps, généralement les organigrammes sont principalement pour quand j'essaie de comprendre un problème particulier.
user133018
L'utilisation de couloirs résout beaucoup de problèmes avec les organigrammes. J'ai trouvé que l'utilisation d'un diagramme de séquence par scénario fonctionne mieux. Chaque scénario couvre un chemin spécifique à travers l'arbre de décision, il n'y a donc pas de FI dans le flux. Si vous voulez avoir un seul diagramme avec tout le flux, vous devez inclure les points de décision, mais il devient rapidement encombré, surtout si vous voulez inclure l'attribution des responsabilités.
Kelly S. French
1

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.

Mike J
la source
1

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.

Darius
la source