Comment avez-vous obtenu de bonnes pratiques pour vos conceptions POO? [fermé]

J'ai réalisé que j'avais du mal à créer des designs OOP. J'ai passé beaucoup de temps à décider si cette propriété est correctement définie sur la classe X.

Par exemple, il s'agit d'un article qui a quelques jours: /codereview/8041/how-to-improve-my-factory-design

Je ne suis pas convaincu de mon code. Je veux donc améliorer mes créations, prendre moins de temps à les créer.

Comment avez-vous appris à créer de bons designs? Quelques livres que vous pouvez me recommander?

La conception de systèmes est l'une des choses que vous ne pouvez améliorer qu'en faisant. Bien sûr, cela aide un peu à lire sur une bonne conception - le livre de conception orienté objet général recommandé est les modèles de conception de Gang of Four : Elements of Reusable Object-Oriented Software . Il existe également d'autres livres sur les modèles et principes de conception pour différents types de systèmes et dans différents domaines.

Il est également préférable d'impliquer d'autres personnes. Après avoir créé une conception, présentez le (s) problème (s) que vous résolvez et la conception à d'autres personnes pour un examen critique. Écoutez leurs commentaires et discutez avec eux, en vous concentrant sur les raisons pour lesquelles vous avez pris les décisions que vous avez prises. Au fur et à mesure que vous implémentez la solution, vous constaterez d'autres problèmes avec votre conception. Prenez-en note et apprenez d'eux. Il peut également être judicieux de travailler avec d'autres personnes pour examiner également la mise en œuvre par rapport à la conception et aux exigences, et avoir une discussion critique des raisons pour lesquelles vous avez fait les choses que vous avez faites.

Bien que je trouve généralement préférable de m'asseoir face à face avec d'autres personnes, des questions de conception spécifiques peuvent être posées ici sur les programmeurs. Il existe également des sites Stack Exchange pour les révisions de code et les questions d' implémentation .

D'après l'apparence de la question de révision du code que vous avez posée, vous êtes en train d'en faire trop. Je pense que c'est un problème assez courant chez les personnes qui découvrent l'importance d'un bon design.

C'est en fait une étape naturelle et probablement même nécessaire avec toutes les compétences que vous ramassez. Lorsque vous commencez à apprendre quelque chose, plus vous progressez dans la connaissance d'une compétence et plus vous l'appliquez, meilleurs sont vos résultats et il semble que vous vous dirigiez directement vers la maîtrise. Le problème est que votre nouvel objectif ne devient pas la qualité de vos résultats, mais la quantité de connaissances que vous avez accumulées sur votre compétence.

La véritable maîtrise d'une compétence implique de comprendre quand l'utiliser et quand ne pas l'utiliser. L'utilisation excessive de cette compétence est probablement le seul moyen de développer une telle compréhension. Bien sûr, vous pouvez lire à ce sujet, mais la lecture ne remplace pas l'expérience.

D'une part, la lecture des modèles de conception est un mauvais départ à mon humble avis. La lecture des principes de conception OO, tels que SOLID et GRASP est meilleure. Après les avoir connus, l'étude des modèles de conception courants est une bonne idée, car vous verrez comment ces principes peuvent être appliqués pour former des idiomes concrets.

On prétend que lorsque des modèles émergent dans l'utilisation d'une langue, alors la langue manque en fait de fonctionnalité. Bien que cette déclaration soit très radicale, elle contient beaucoup de vérité. Par conséquent, je vous suggère de regarder et de jouer avec d'autres langues pour mieux comprendre les concepts que vous cherchez à utiliser et également pour en apprendre davantage sur de nouveaux concepts. Une liste restreinte serait Squeak, Ruby et Lisp.
Quant à List, ma recommandation personnelle est Structure et interprétation des programmes informatiques , qui m'a beaucoup appris sur la conception, en me montrant à quel point on peut créer sans effort des solutions robustes à des problèmes complexes, avec à peine plus d'abstraction claire et de (dé) composition en de manière descendante.

Voici donc ce que je suggère:

1. écrire du code (et essayer de comprendre ce qui le rend mauvais)
2. lire le code (et essayer de comprendre ce qui le rend bon)
3. échanger des connaissances avec d'autres personnes. mettez vos idées à l'épreuve.

Comme d'autres l'ont mentionné, vous ne serez bon qu'avec la pratique et l'expérience. Il n'y a pas vraiment de raccourci que vous puissiez prendre.

Le fait que vous regardiez en arrière et que vous n'aimiez pas ce que vous avez écrit, vous place déjà en avance par rapport à de nombreuses autres personnes de notre profession. Pendant que vous essayez de vous améliorer, le reste d'entre nous travaille avec des gens qui écriraient une fonction de 500 lignes avec 20 paramètres, tous transmis par référence et 15 d'entre eux étant [in / out] et ces gens pensent qu'ils sont la bombe parce qu'ils ont mis ce désordre au travail.

Quand il s'agit de conception de logiciels, ce n'est pas en noir et blanc, que la conception soit bonne ou mauvaise. Quelle que soit votre expérience, vous reviendrez à certains de vos anciens codes et vous vous demanderez "qu'est-ce que je fumais quand j'ai écrit ça?" La clé est une évaluation constante des choses et un examen fréquent des exercices de réflexion pour évaluer ce qui rend un bon code bon et mauvais.

Enfin, bien que rien ne remplace la pratique, c'est toujours une bonne idée de toujours lire les blogs / livres / ce site car d'autres personnes vous indiqueront des perspectives différentes que vous n'avez peut-être pas envisagées.

Pour commencer, je recommanderais ces livres:

• Principes, modèles et pratiques agiles en C # - Je suis moi-même 3 / 4ème à travers ce livre. L'un des principaux arguments de l'auteur, et je suis d'accord à 100% avec cela, ne commencez pas par résoudre un problème en recherchant un modèle de conception à appliquer. Gardez les choses aussi simples que possible et faites évoluer le code dans un modèle, si l'alternative commence à devenir plus compliquée que cela.
• Modèles de conception Head First - Je n'ai pas lu ce livre et à l'OMI, de nombreuses séries Head First sont spécifiquement destinées aux nouveaux arrivants sur le terrain. Donc, ils ont tendance à être plus simples, mais j'ai entendu / lu de nombreuses bonnes réponses des autres sur ce livre

La conception à l'avant n'est jamais aussi bonne que la conception à l'arrière. Il suffit de tester, de coder et de refactoriser. Lorsque les choses sont laides et que vous ne savez pas comment les nettoyer, voyez si un motif de conception vous aidera. Pratiquez-le pendant un certain temps et bientôt d'autres développeurs vous demanderont comment vous arrivez à des conceptions aussi épurées.