Introduction
Robert L. Glass a soutenu que la pratique précède la théorie. Le développement de logiciels est un domaine représentatif où la pratique est en avance sur la théorie, et les développeurs acquièrent le plus de connaissances lorsqu'ils se «salissent les mains» en manipulant du code concret. Par conséquent, nous allons mettre de côté la théorie et les concepts pour le moment et examiner un programme simple.
Implémentation d'une application de vente de billets
- Nous prévoyons d'organiser un petit événement pour promouvoir un petit théâtre.
- Contenu de l'événement : envoi d'invitations gratuites à un spectacle sélectionné au hasard parmi les spectateurs
- Il faut distinguer les spectateurs qui ont gagné l'événement de ceux qui ne l'ont pas gagné.
- Spectateurs gagnants de l'événement : échange de l'invitation contre un billet
- Spectateurs perdants de l'événement : achat de billets avec de l'argent
Code de pratique :https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01
Quel est le problème ?
Robert Martin explique les trois fonctions qu'un module logiciel (quel que soit sa taille, un élément arbitraire constituant un programme, tel qu'une classe, un package ou une bibliothèque) doit remplir.
- Fonctionne correctement pendant l'exécution.
- Existe pour la modification.
- La modification doit être possible avec des opérations simples.
- Communique avec la personne qui lit le code.
- Les développeurs doivent pouvoir le lire et le comprendre facilement.
L'application de vente de billets précédente satisfait la première contrainte, qui est de s'exécuter correctement, mais ne satisfait pas les objectifs de facilité de modification et de communication.
Code qui dévie des attentes
Examinons la raison pour laquelle l'objectif de communication n'est pas atteint.
- Ce que fait la méthode enter() de la classe Theater
- Le théâtre ouvre le sac du spectateur pour vérifier s'il contient une invitation.
- S'il y a une invitation dans le sac, il demande au vendeur de déplacer le billet qui est stocké à la billetterie vers le sac du spectateur.
- S'il n'y a pas d'invitation dans le sac, il prend de l'argent dans le sac du spectateur pour acheter un billet, puis place le billet dans le sac.
- Du point de vue du spectateur, il doit regarder le théâtre, un tiers, fouiller dans son sac, prendre de l'argent et y mettre un billet.
- Du point de vue du vendeur, il doit regarder le théâtre, un tiers, manipuler les billets et l'argent à la billetterie sans autorisation.
- Un code compréhensible signifie un code dont le fonctionnement ne s'écarte pas trop de nos attentes, mais le théâtre ci-dessus dévie de nos attentes.
- Le spectateur doit sortir l'argent de son sac et le payer au vendeur pour obtenir un billet.
- Le vendeur doit sortir le billet de la billetterie et le remettre au spectateur, puis recevoir l'argent du spectateur et le conserver à la billetterie.
- De plus, pour comprendre la méthode enter(), il faut se souvenir de nombreux détails.
- Audience possède Bag.
- Bag contient de l'argent et un billet.
- TiketSellet vend des billets à TicketOffice, et TicketOffice stocke de l'argent et des billets.
Code vulnérable aux modifications
La méthode enter() suppose deux conditions.
- Les spectateurs ont toujours un sac pour ranger leur argent et leurs invitations.
- Le vendeur vend des billets uniquement à la billetterie.
Que se passe-t-il alors dans les situations suivantes ?
- Les spectateurs peuvent ne pas avoir de sac.
- Les spectateurs peuvent utiliser une carte de crédit au lieu d'espèces.
- Le vendeur peut vendre des billets en dehors de la billetterie.
Par exemple, pour satisfaire la première exigence, il faut supprimer l'objet Bag de Audience et modifier la méthode enter() de la classe Theater qui y est liée. En effet, la classe Theater dépend trop de faits trop détaillés, tels que le fait que les spectateurs ont un sac et que le vendeur vend des billets uniquement à la billetterie. Si l'un de ces détails change, il faut modifier à la fois la classe concernée et les classes qui en dépendent (ex. Theater).
Ceci est un problème lié à la dépendance entre les objets, et la dépendance implique l'impact des modifications. Cependant, comme la conception orientée objet vise à construire une communauté d'objets qui coopèrent tout en étant interdépendants, il ne faut pas supprimer la dépendance aveuglément, mais plutôt maintenir « la dépendance minimalenécessaire pour implémenter les fonctionnalités de l'application et supprimer les dépendances inutiles.
On dit que le cas où la dépendance entre les objets est excessive est une forte cohésion, et plus la cohésion entre deux objets est forte, plus la probabilité qu'ils soient modifiés ensemble est élevée. Par conséquent, l'objectif de la conception est de réduire la cohésion entre les objets afin de créer une conception facilement modifiable.
Améliorer la conception
Theater n'a pas besoin de savoir que les spectateurs ont un sac et que le vendeur vend des billets à la billetterie. Theater veut simplement que les spectateurs entrent dans le théâtre. Par conséquent, il faut faire en sorte que les spectateurs gèrent eux-mêmes l'argent et les invitations dans leur sac, et que le vendeur gère lui-même les billets et les prix à la billetterie, en tant qu'entités autonomes.
Augmenter l'autonomie
On dit qu'un objet qui effectue uniquement des tâches étroitement liées et délègue les tâches non liées à d'autres objets a une forte cohésion. La création d'objets autonomes qui gèrent leurs propres données permet de réduire la cohésion et d'augmenter la cohésion.
Programmation procédurale et programmation orientée objet
- Programmation procédurale
- La méthode enter() de Theater est un processus, et Audience, TicketSeller, Bag et TicketOffice sont des données.
- La méthode qui place les processus et les données dans des modules distincts est appelée programmation procédurale.
- Il y a beaucoup de code qui va à l'encontre de notre intuition. (ex. Les spectateurs gèrent eux-mêmes l'argent et les invitations.)
- Il est difficile de limiter l'impact des modifications de données.
- La responsabilité est gérée de manière centralisée. (Theater gère tout.)
- Programmation orientée objet
- La méthode qui place les données et les processus dans le même module est appelée programmation orientée objet.
- Vous pouvez écrire du code qui correspond à notre intuition.
- L'impact des modifications de données peut être efficacement limité grâce à l'encapsulation.
- Chaque objet est responsable de lui-même.
Code de pratique :https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02
On peut encore l'améliorer.
- La classe Bag de la classe Audience est toujours une entité passive entraînée par la classe Audience, il faut donc faire de la classe Bag une entité autonome.
- TicketOffice de la classe TicketSeller est également géré arbitrairement par TicketSeller. Il faut faire de TicketOffice une entité autonome.
- Cependant, après la modification, TicketOffice a une cohésion supplémentaire avec Audience.
- Comme la conception implique un compromis, dans ce cas, on peut convenir de faire de TicketOffice une entité quelque peu passive afin de réduire la cohésion avec Audience.
Code de pratique :https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03
Eh bien, c'est un mensonge !
- Dans la réalité, même si c'est une entité passive, une fois qu'elle entre dans le monde de l'orientation objet, tout devient une entité active et autonome.
- Il est préférable d'utiliser la personnification et de considérer les objets passifs comme des entités qui rient, parlent et se mettent en colère.
Conception orientée objet
Pourquoi la conception est-elle nécessaire ?
- La conception consiste à organiser le code.
- Une bonne conception est une conception qui remplit parfaitement les fonctions requises aujourd'hui et qui peut facilement accepter les changements futurs.
Conception orientée objet
- Un code modifiable est un code facile à comprendre.
- Le paradigme orienté objet aide à écrire du code de la même manière que nous voyons le monde.
- Un objet est une entité autonome qui est responsable de ses propres données.
- Une excellente conception orientée objet est une conception qui gère correctement les dépendances entre les objets qui coopèrent.
Source
- Objet
Commentaires0