Comment savoir ce qui doit être fait dans la conception orientée objet?


12

Tout d'abord un avertissement: je ne sais pas vraiment si cette question correspond à ce site Web, mais je la trouve toujours une question pertinente non seulement pour moi mais pour d'autres personnes qui sont débutants. Si la question peut être améliorée pour s'adapter ici, veuillez indiquer les commentaires int. Si cela ne vous convient pas, faites-le moi savoir et si possible, faites-moi savoir où cela peut être discuté car je n'ai pas trouvé de bons forums pour cela.

J'ai appris à programmer en 2009 lorsque j'ai étudié PHP. Plus tard en 2012, je suis passé à C # et .NET. Quoi qu'il en soit, le codage n'est pas le problème, l'écriture d'algorithmes n'est pas mon problème. Mon problème réel est de savoir ce qui doit être codé pour répondre à une exigence et il doit être codé.

La plupart des cours disponibles sur le Web abordent le comment - comment écrire du code dans une certaine langue, comment utiliser certains ensembles d'API, etc. Ce n'est pas mon point ici.

Au cours de ces années, j'ai lu beaucoup de choses sur un tas de choses: l'analyse et la conception orientées objet, les modèles de conception, la conception pilotée par domaine, etc. Je comprends par exemple les principes SOLID, certaines des principales idées de DDD comme la nécessité de l'engagement d'experts du domaine, le développement d'un langage omniprésent et ainsi de suite. J'oserais dire que j'ai une formation théorique au moins raisonnable.

Mais quand il s'agit de pratiquer, j'ai l'impression d'être un désastre. Il y a quelque temps, je devais poursuivre le développement d'un système financier déjà développé par quelqu'un d'autre. C'est ce genre d '"ancien système" développé avec C # et WinForms. C'était la première fois que je choisissais un projet avec une réelle complexité de domaine, avec beaucoup de règles métier, etc.

J'avoue que lorsque je reçois les exigences la plupart du temps, je pense "comment diable cela peut-il être fait?" - Je n'ai aucune idée de la façon même de commencer à travailler sur les exigences pour comprendre ce qui doit être fait. Je crois que mes confusions principales sont ce que je dois coder, quelles classes, interfaces et où chaque élément logique va, sur quelle classe chaque chose doit être. Le problème est que je ne sais pas par où commencer.

La plupart du temps, avec beaucoup de réflexion, je me retrouve avec quelques idées, mais je ne sais jamais juger si mon idée est correcte ou non.

Je veux dire que je ne pense pas que ce soit un manque de théorie, comme je l'ai dit, j'ai lu un tas de choses sur l'architecture logicielle et l'orientation des objets, on m'a recommandé mais cela n'a pas beaucoup aidé à identifier ce qui doit être fait dans la pratique .

Alors, comment puis-je apprendre à vraiment faire du design orienté objet? Ce que je veux apprendre, c'est: les exigences données savent comment commencer à travailler sur elles dans un processus qui conduit à découvrir ce qui doit être fait et où chaque morceau de code appartient. Comment puis-je également apprendre à juger si mon idée est correcte ou non?

Je pense qu'il ne serait pas possible d'expliquer pleinement cela comme une réponse ici. Ce que je recherche, cependant, qui peut être selon le style du site, ce sont des réponses donnant simplement un aperçu et pointant quelques références (livres, cours en ligne, etc.) qui peuvent être utilisées pour développer les idées et vraiment apprendre ces choses.


1. Comprenez-vous déjà tous les concepts fondamentaux de C #, y compris des choses comme la différence entre la surcharge d'opérateur et la surcharge d'opérateur, ce qu'est une classe abstraite et comment elle est différente d'une interface, encapsulation, polymorphisme, etc.? Connaître ces choses en premier est essentiel pour bien comprendre OO en C #. Voir c-sharpcorner.com/technologies/oop-ood .
Robert Harvey

2
2. Les applications plus anciennes écrites dans Winforms ont tendance à se transformer en grosses boules de boue à moins d'être correctement architecturées. La séparation des préoccupations devient primordiale. Voir winformsmvp.codeplex.com
Robert Harvey

1
Il n'y a pas vraiment de processus. Le design consiste principalement à savoir organiser, ce qui vient avec l'expérience. Les principes SOLID sont un bon début, mais ils ne suffisent pas, et les gens ont tendance à se perdre dans SOLID et à oublier pourquoi les principes existent.
Robert Harvey

1
Commencez peu. Les exigences sont des problèmes. Un problème peut être aussi énorme que "Nous voulons développer le prochain site Stackexchange" ou aussi peu que "nous voulons que notre prochain Stackexchange ait une connexion". Transformez un gros problème en plusieurs mais plus petits. Dans l'ensemble, donnez-vous la chance de faire les choses "mal" en premier et d'améliorer au fil du temps.
Laiv

1
Je veux simultanément voter et vtc ce ...
svidgen

Réponses:


21

Alors, comment puis-je apprendre à vraiment faire de la conception orientée objet? Ce que je veux apprendre est: les exigences données savent comment commencer à travailler sur elles dans un processus qui conduit à découvrir ce qui doit être fait et où chaque morceau de code appartient. Comment puis-je également apprendre à juger si mon idée est correcte ou non?

Eh bien tout d'abord, arrêtez de penser que la conception orientée objet est correcte. C'est comme penser que l'anglais est correct.

Le paradigme orienté objet n'est pas correct. Il présente certains avantages et inconvénients. C'est un idéal. Ce n'est pas notre seul. C'est mieux que rien mais ce n'est certainement pas tout.

Je code depuis des décennies maintenant. J'étudie ce truc depuis presque aussi longtemps que ses idées existent. J'apprends toujours ce que cela signifie. Les experts apprennent encore ce que cela signifie. Notre domaine entier a moins de 100 ans.

Donc, lorsque vous prenez une pile d'exigences et que vous obtenez du code qui les satisfait tout en ayant l'impression que le code que vous avez écrit est un gâchis tragique, vous n'êtes pas seul. Le code de travail est simplement la première étape vers un bon code. Un code qui fonctionne non seulement mais que les autres peuvent lire et comprendre facilement. Code adaptable rapidement lorsque les besoins changent. Code qui vous donne envie de vous asseoir et de dire "Wow, c'est si simple".

Le problème est que nous ne sommes pas payés pour faire tout cela. Nous faisons tout cela parce que nous sommes des professionnels. Nous devons faire tout cela quand le patron ne regarde pas parce qu'il y a toujours un délai. Mais nous voulons revenir dans 5 ans et dire aux débutants: "Oh ouais, j'ai écrit ça. Ça marche toujours hein? Cool."

Comment y arrivez-vous? Entraine toi. N'acceptez AUCUNE idée de conception sur la foi. Quelqu'un ne se taire pas sur la façon dont la conception événementielle simplifiera cette conception? Vous ne savez pas s'ils ont raison? Construisez votre propre projet de jouet à la maison en utilisant le modèle d'observateur. Joue avec ça. Essayez de trouver des choses avec lesquelles cela N'AIDE PAS.

Lis. Question. Tester. Répéter.

Lorsque vous arrivez au point que vous le faites depuis 80% de votre vie, vous serez aussi confus que moi.

J'avoue que lorsque je reçois les exigences la plupart du temps, je pense "comment diable cela peut-il être fait?" - Je n'ai aucune idée de la façon même de commencer à travailler sur les exigences pour comprendre ce qui doit être fait. Je crois que mes confusions principales sont ce que je dois coder, quelles classes, interfaces et où chaque élément logique va, sur quelle classe chaque chose doit être. Le problème est que je ne sais pas par où commencer.

J'avais l'habitude de ressentir la même chose. Puis j'ai découvert la joie du refactoring. Soyez prêt à adapter les conceptions au fur et à mesure que vous codez. Essayer de tout régler sur papier à l'avance est la manière la plus difficile de le faire. Écrivez du code qui peut être prouvé faux, prouvez-le faux et corrigez-le.


2
C'est une excellente réponse. Je programme depuis 15 ans, et j'ajouterai que tout le domaine du génie logiciel (ma profession) est "flou" - c'est un mélange d'art et de fonction, et selon le développeur est plus l'un que l'autre. Je peux trouver une idée d'architecture sur papier, mais je ne pourrai jamais travailler sur les détails de la conception OO jusqu'à ce que j'entre dans la saleté, déconne et trouve ce qui fonctionne et ce qui ne fonctionne pas.
jropella

Merci d'avoir répondu! Votre point est donc le suivant: une fois que nous avons au moins une solution pour implémenter une exigence, et que cela fonctionne, nous l'implémentons, puis comme nous voyons comment elle se rapporte à l'autre code et à d'autres exigences, nous la remodelons pour la rendre meilleure? Mais il y a encore des situations où je reçois certaines exigences et je n'ai aucune idée de la façon de commencer. Dans ce cas, avez-vous des conseils sur la façon de commencer? Parfois, je crois que le mieux serait de discuter des exigences et des implémentations possibles, mais je travaille seul. Y a-t-il un forum où ce genre de discussion est le bienvenu?
user1620696

2
Eh bien d'abord, arrêtez de travailler seul. Même avoir un débutant désemparé qui vous ralentit pour expliquer les choses est mieux que ça. Deuxièmement, apprenez à diviser une exigence en plusieurs parties. Continuez à faire cela jusqu'à ce que vous ayez quelque chose de gérable sur lequel vous pouvez obtenir une traction. Écrivez le code de preuve de concept dans un environnement complètement différent si nécessaire. Faites simplement quelque chose qui exprime votre compréhension de ce qui est nécessaire. Testez ensuite cette expression. Vous pouvez trouver de mauvaises hypothèses. C'est bon. Soyez prêt à les changer.
candied_orange

1

Le développement de logiciels se résume à la livraison de logiciels fonctionnels, dans les délais et dans le respect du budget tout en répondant à tous vos critères d'acceptation. En supposant que vous ayez réussi à le faire, la qualité perçue du code ou de sa structure est une préoccupation secondaire.

Le problème est bien sûr que l'écriture de nouveau code greenfield a tendance à être beaucoup moins cher et plus facile que la maintenance du code hérité, donc plutôt que d'être trop accroché à la qualité ou à l'architecture du code, n'oubliez pas que votre véritable problème est la maintenabilité.

En règle générale, le code est considéré comme maintenable lorsque les coûts, le temps et les risques associés à la modification de ce code sont proportionnellement suffisamment bas pour que la correction de bogues ou la mise en œuvre de modifications des exigences soit toujours rentable, et qu'en mettant en œuvre ces modifications, vous ne perpétuez pas une «spirale de la mort» "de code-entropie.

À l'inverse, le code est considéré comme non maintenable lorsque vous ne pouvez pas changer ou refactoriser en toute confiance sans risque sérieux de casser quelque chose ou de dépenser trop de temps / d'argent pour vous assurer que rien n'est cassé - c'est-à-dire lorsque le temps, les coûts et les risques liés à l'utilisation de ce code sont disproportionnellement élevé par rapport aux avantages de faire des changements (c.-à-d. que votre employeur ou client ne perd pas d'argent en ajoutant de nouvelles fonctionnalités, en corrigeant des bogues, etc.)

Rappelez-vous que même le désordre de spaghetti le plus diabolique peut être potentiellement maintenable si vous avez suffisamment de provisions autour du désordre pour vous protéger contre les changements de rupture (bien que de tels cas soient rares). Le problème avec un désordre de spaghetti est que le protéger contre les changements de rupture a tendance à être assez cher et inefficace - surtout si vous le faites rétrospectivement.

Le moyen le plus fiable pour vous assurer que vous avez écrit du code maintenable est peut-être d'écrire (lorsque cela est raisonnablement possible) une suite adéquate de tests automatisés en même temps (tout en tirant pleinement parti de tout autre outil d'analyse statique qui pourrait être disponible).

Vous n'avez pas particulièrement besoin de suivre une méthodologie de développement stricte telle que TDD / BDD afin de vous retrouver avec suffisamment de tests automatisés pour vous permettre de refactoriser; vous en avez juste besoin pour protéger le code contre les modifications accidentelles à l'avenir.

Si votre code est couvert par des tests automatisés, vous pouvez vous détendre sur sa conception et sa structure en sachant que vous êtes couvert par ces tests; vous pouvez refactoriser agressivement à une date ultérieure, ou même le jeter et recommencer.

Cela soulève la question de savoir comment écrire du code facilement testable; c'est généralement l'argument principal pour suivre les principes SOLID; en fait, la caractéristique du code qui adhère aux principes SOLID est qu'il est facile et rentable d'économiser des tests unitaires.

Bien sûr, vous n'avez parfois pas non plus le temps d'écrire des tests unitaires; cependant, si vous avez écrit tout votre code tout en gardant à l'esprit la question "Comment écrire des tests automatisés pour cela?" (même si vous n'avez pas réellement implémenté ces tests), vous avez probablement également réussi à trouver une conception raisonnablement maintenable.


1
nous n'avons jamais le temps d'écrire des tests automatisés mais nous avons toujours le temps d'exécuter des tests manuels encore et encore ...
Nick Keighley

De même, nous n'avons jamais le temps d'écrire le code "correctement" et "proprement" la première fois mais nous semblons avoir un temps infini pour continuer à revenir en arrière et à le réparer, encore et encore à cause de l'état d'esprit erroné mais si répandu présenté dans ce post.
Dunk

@Dunk Je ne pense pas qu'il soit réaliste de s'attendre à ce que le code ne change ni ne soit revu. Les pratiques de test unitaire et les directives SOLID consistent à encourager les pratiques qui aboutissent à un code facile et peu coûteux à changer lorsque l'inévitable se produit - par exemple, quelqu'un trouve un bogue obscur vraiment bizarre que le développeur n'a pas pris en compte à l'époque, ou le client voit le solution et modifie les exigences, ou même le code d'origine contenait des erreurs car les développeurs ne sont que des humains; ou peut-être que le développeur a mal compris les exigences, ou a découvert des limitations techniques jusque-là inconnues ...
Ben Cottrell

1
@BenCottrell - Je suis totalement d'accord. Le code devra toujours être revu. Cependant, à cause de cela, cela amène les gens à indiquer qu'il faut prendre le temps de faire une «conception initiale» et écrire un peu de «code propre» comme une sorte d'échec. Ils utilisent le mantra «à temps» et «à budget» pour justifier un code / une conception médiocre. Vous pouvez utiliser toutes les "pratiques" que vous souhaitez mais cela ne vous achètera pas "du code qui est facile et bon marché à changer" sans avoir un bon design et un "code relativement propre" pour commencer. Une bonne conception et un «code propre» auront pour sous-produit d'atteindre réellement l'objectif de respect des délais et du budget.
Dunk

@Dunk On dirait que vous dites que de nombreux développeurs ne se soucient pas de la qualité du code, ce qui, je ne pense pas, est généralement le cas. En réalité, je pense qu'il y a deux problèmes plus importants - premièrement, alors que les développeurs peuvent être ceux qui fournissent une estimation du budget et du délai, les estimations peuvent facilement se révéler fausses. Deuxièmement, les parties prenantes du projet ont le dernier mot sur le temps et les coûts, ce qui signifie que les risques, les budgets et les délais l'emportent sur les préoccupations techniques. Étant donné le choix entre "définitivement en retard / dépassement de budget" ou "potentiellement mauvais code", je trouve que les parties prenantes choisissent fréquemment ce dernier.
Ben Cottrell
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.