Comment passer du mauvais au bon design POO?

Question

Je lis beaucoup sur les bonnes et les mauvaises pratiques en matière de conception orientée objet. Il est bon de savoir que votre conception est mauvaise ou bonne. Mais comment passer du mauvais au bon design? J'ai séparé l'interface (xaml) et le codebehind de la classe principale de businesslogic. Ce dernier cours devient grand. J'ai essayé de le diviser en classes plus petites, mais je suis coincé maintenant. Des idées sur la façon de diviser de grandes classes? La classe principale a 1 liste de données de types différents. Je fais des calculs sur le total, mais aussi sur les types individuels. J'ai des méthodes pour effectuer ces calculs qui sont appelées à partir d'événements gérés dans le code ci-dessous. Des idées où aller d'ici?

Informations supplémentaires:

Nous en sommes déjà à environ 6 mois dans ce projet. Cela fait des années que je travaille avec des langages orientés objet (d'abord c ++, java et maintenant c #), mais jamais sur un gros projet comme celui-ci. Je pense que nous avons mal tourné au début et que nous devons les corriger. Je ne peux pas spécifier de détails sur ce projet pour le moment. Je vais commander un ou deux livres sur le design. Si je sépare toutes les classes, comment puis-je les coller ensemble? Peut-être que c'est encore mieux de continuer ainsi jusqu'à la première version et de reconstruire les parties après cela, pour une deuxième version?

Answer 1

  

La classe principale a 1 liste de données de   différents types. Je fais   calculs sur le total, mais aussi sur   les types individuels. J'ai des méthodes   d'effectuer ces calculs qui   sont appelés à partir d'événements gérés dans le   codebehind. Des idées d'où aller   ici?

S'il y a beaucoup de calculs basés sur le contenu de la liste, avez-vous envisagé de déplacer des opérations dans une classe de liste personnalisée? Il en va de même pour les opérations sur les types spécifiques. Peut-être pourraient-ils vivre à l'intérieur des types?

Pour effectuer des opérations similaires mais différentes sur des types différents, envisagez d'utiliser le modèle d'état ( voyez ceci comme un remplacement des instructions switch) qui vous permet de traiter les entités de manière uniforme.

Une grande partie de la programmation orientée objet consiste à abandonner une approche "de haut en bas" / microgestion et à envisager une approche "de bas en haut" / autosuffisante. Il ne faut pas oublier que ni l'une ni l'autre de ces approches n'est "correcte". en isolation. Créer du code maintenable consiste à trouver un équilibre raisonnable qui nécessite beaucoup de réflexion et qui se développe habituellement grâce à l'expérience.

Answer 2

Pratiquez et lisez. Répétez :)

Quelques livres recommandés:

• Clean Code de Robert C Martin
• Modèles de conception GoF
• Refactoring par Martin Fowler

Personnellement, j’ai également aimé les modèles de conception Head First, mais le style ne convient pas forcément à tout le monde. Il existe un livre similaire appelé Modèles de conception C # 3.0 (voir ora.com). Il a une grande partie de la même chose, mais d'une manière plus traditionnelle.

Answer 3

Je recommande vivement de récupérer Code terminé . C'est un excellent livre qui offre des tonnes de bons conseils sur des questions comme la vôtre.

Pour vous donner une réponse rapide à votre question sur la manière de diviser de grandes classes, voici une bonne règle empirique: responsabilisez votre classe pour une chose et une seule. Lorsque vous commencez à penser de la sorte, vous pouvez rapidement identifier un code qui n’appartient pas. Si quelque chose ne vous appartient pas, intégrez-le dans une nouvelle classe et utilisez-le depuis votre classe d'origine.

Modifier: réduisez cette réflexion à la "méthode" niveau aussi - responsabilisez vos méthodes pour une chose et une seule. Aide à décomposer très rapidement les méthodes volumineuses (> 50 lignes) en fragments de code réutilisables.

Answer 4

Modifiez votre façon de penser aux objets. Chaque objet devrait avoir une responsabilité très spécifique. Si vous avez une classe nommée quelque chose de générique, comme "MainBusinessLogic" vous faites probablement quelque chose de mal.

C'est un bon endroit pour commencer: lisez la pensée d'objet de David West.

Answer 5

Ceci n’est qu’un addendum à quelques suggestions de livres raffinées.

Plus je réussis à devenir OO, plus il me semble réduire la taille de l'objet. Ce n'est pas comme si je visais des objets de petite taille ou quoi que ce soit, mais cela semble se produire.

En les gardant petits, une seule responsabilité, simples à utiliser et à comprendre - tous essentiels. Chaque objet doit être aussi proche que possible de l'épreuve des balles, vérifiez vos paramètres et ne laissez jamais votre objet dans un état non valide. Définissez clairement tous les états valides dans la documentation.

Chaque fois que vous créez une classe, créez un test pour cette classe. Il teste non seulement votre code, mais vous oblige à utiliser votre propre conception. Pensez toujours à votre classe à partir de cette "vue extérieure". Assurez-vous de ne pas trop demander à la personne qui utilise votre classe et tout ce que vous lui demandez devrait être documenté dans l'interface. Souvent, je mets simplement une classe dans une classe s’il n’ya pas de framework de test disponible - cela place un exemple d’utilisation du code ici même dans le même fichier.

En codant, je passe presque tout mon temps à essayer de comprendre ce que quelqu'un d'autre a fait. Si je pouvais simplement sortir du code en utilisant des API connues ou bien documentées, mon travail serait trivial et les horaires beaucoup plus courts.

Le design d’abord peut être difficile. Considérez la capacité de codage comme similaire à la capacité sportive. La plupart d’entre nous jouons dans nos allées, quelques-uns au sein d’équipes sportives locales. Faire un bon design initial sur un projet compliqué est la tâche d'un joueur de la ligue nationale, ils sont un sur un million. Acceptez ceci et planifiez le changement - les itérations sont votre ami. (Au fait, la plupart d’entre nous pensent que nous sommes facilement au niveau de l’Etat. Nous ne le sommes pas).

Answer 6

En plus de la recommandation de Brian sur Clean Code par Robert C Martin , vous souhaiterez peut-être lire des informations sur "Oncle Bob's". Principes SOLID de la conception orientée objet .

Vous l'entendez parler des principes SOLID sur Hanselminutes Podcast 145 . code sur Rocks .NET! Affichez le numéro 388 . Il a également d'autres contacts avec lui sur Rocks .NET! Montrez le # 410 , mais ce dont il parle n’est pas vraiment lié à votre question, je l’ai simplement incluse au cas où vous auriez aimé les deux premiers.

Parmi les trois podcasts, j’ai préféré les Hanselminutes.

Answer 7

Refactoring de Martin Fowler est un excellent livre sur la façon de modifier le conception de votre logiciel sans le casser.

Modèles de conception fonctionne de la même manière que les algorithmes mais vous indique comment combiner des objets. effectuer diverses tâches utiles.

Enfin, Martin Fowler propose divers modèles de conception utiles pour les applications. Par exemple, affichage passif

Answer 8

La "Utiliser efficacement le code hérité" de Michael Feathers est supposée: être très bon, mais je vais avouer que je ne l'ai pas lu moi-même.

Idem pour le Refactoring en modèles. "

Answer 9

J'ai découvert que travailler sur une "tâche" complexe sans aide, puis voir comment quelqu'un d'autre l'avait fait, a été une grande expérience d'apprentissage pour moi.

Une tâche en particulier consistait à créer un programme de type bancaire dans le cadre duquel nous devions suivre les transactions et être en mesure de calculer les intérêts gagnés, etc. C'était vraiment mon premier programme POO et un très bon programme en raison de sa complexité. Il est beaucoup trop déroutant (pour un débutant) de le faire dans un style linéaire sans commettre d'erreur.

Answer 10

Je ne peux que dire ce qui fonctionne pour moi, et comme je n'ai trouvé personne qui travaille de la même manière, je ne suis pas sûr que cela vous aidera beaucoup.

En gros, mon approche consiste à avoir le moins de classes possible, mais pas moins.

Tout d’abord, vous ne devez enregistrer des informations que si vous les recevez à l’heure A et si vous en avez besoin ultérieurement B. Si vous les obtenez et que vous les travaillez en même temps, il se peut qu’elles ne soient pas nécessaires. pour le stocker.

Deuxièmement, que faites-vous avec cela? Si vous allez y parcourir de manière simplifiée, vous pouvez le considérer comme un jeu d'instructions et le programme qui le gère comme un interprète d'un jeu d'instructions. Dans ce cas, vous voudrez peut-être concevoir un jeu d'instructions codé par octet, avec un interprète, et coder vos informations dans ce jeu d'instructions.

Troisièmement, à quelle fréquence les informations changent-elles? Si certaines informations ne changent que très peu souvent, vous pourrez peut-être utiliser une évaluation partielle (c.-à-d. La génération de code). Autrement dit, vous prenez les informations qui changent peu fréquemment et vous les utilisez pour générer un programme ad-hoc qui fait ce que votre programme global ferait avec ces informations, mais beaucoup plus rapidement. Le générateur de code est facile à écrire car il ne traite qu’une partie des informations d’entrée, la partie qui change lentement.

Une grande partie de la structure de données que je vois de nos jours existe pour prendre en charge l'interface utilisateur. Il ne s'agit clairement pas d'objets qui tiennent à l'utilisateur, et idéalement, vous ne devriez pas non plus vous en soucier. J'ai donc construit un DSL pour les UIs qui cache tout ce qui est foutu.

Éloignez-vous des événements et des notifications si vous le pouvez, car ils se produisent à des moments précis et représentent donc des changements incrémentiels d'état. Vous devrez être extrêmement inquiet de leur éventuelle suppression, duplication ou erreur de commande. Ils sont souvent utilisés sur la théorie selon laquelle un style de sondage simple serait "moins efficace". alors que c’est souvent l’inverse qui se produit.

Ainsi, lorsque je vois des gens se plonger dans la technologie des cours, etc., c'est généralement parce qu'ils font une trop grande quantité de structure de données.

Juste mon appât à vote négatif ...

Answer 11

Je recommande de Feather de travailler efficacement avec le code hérité , disponible et consultable sur Safari , sur le la refactorisation . Il regorge de chapitres utiles et empathiques tels que Je n'ai pas beaucoup de temps et je dois le changer et Mon application n'a pas de structure.

Points de vue à prendre en compte:

1. Automatisation des tests de qualité de conception: recherchez des outils fournissant des mesures de la qualité de la conception, afin de vérifier vos décisions de conception.
2. Testabilité du code - certains de vos refactorings aident-ils ou entravent-ils le développement piloté par les tests, la rédaction de tests unitaires ou la rédaction de tests fonctionnels? A quel point sera-t-il difficile de tester de gros éléments de l'architecture une fois intégrée?
3. Justification - Comment défendez-vous ces décisions, d’un CAY à un management cynique et, plus important encore, pour que votre équipe croie en la nouvelle conception. Pouvez-vous expliquer facilement et systématiquement pourquoi pourquoi un changement a été apporté et cette explication sera-t-elle facile à trouver dans 6 mois?

Préférences personnelles dans la conception, notamment le refactoring:

1. Classes pour les concepts - en cas de doute, s'il existe un seul concept clair, il doit être encapsulé dans une classe plutôt que sous-entendu en tant que comportement dans un ou dans des méthodes.
2. Il est plus facile de penser et d’auditer de nombreuses petites choses qui communiquent avec des responsabilités . En cas de doute sur la manière dont une conception correspond au monde réel, revenez à l'ancienne Responsibility-Driven- Concevez pour noter les responsabilités de chaque classe. Si vous trouvez cela difficile, vos concepts de ce que chaque classe fait peuvent être confus ou en faire trop.
3. Ne soyez pas effrayé par la taille des choses si elles sont régulières. Parfois, par exemple: de nombreux gestionnaires d’événements sur des interfaces graphiques, vous aurez légitimement des classes avec beaucoup plus de méthodes ou de propriétés que ne le recommandent les métriques.

Answer 12

Essayer d'écrire un code plus testable, cela seul m'a obligé à rechercher et à mettre en œuvre de meilleurs concepts / pratiques de POO.