Introduction

Robert L. Glass a soutenu que la pratique précède la théorie. En particulier, le développement logiciel est l'un des domaines où la pratique est en avance sur la théorie, et les développeurs apprennent le plus en se salissant les mains avec du code concret. Par conséquent, nous allons mettre la théorie et les concepts de côté pour le moment et examiner un simple programme.

Implémentation d'une application de billetterie

• Nous prévoyons d'organiser un petit événement pour promouvoir un petit théâtre.
  • Contenu de l'événement : envoyer des invitations gratuites à un spectacle aux spectateurs sélectionnés par tirage au sort.
• Nous devons séparer les spectateurs qui ont gagné l'événement de ceux qui ne l'ont pas fait.
  • Spectateurs gagnants de l'événement : échangez les invitations contre des billets.
  • Spectateurs perdants de l'événement : achetez des billets avec de l'argent.

Code 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 fonctionnalités qu'un module logiciel (un élément quelconque d'un programme, quelle que soit sa taille, comme une classe, un package ou une bibliothèque) doit avoir.

• Fonctionne correctement pendant l'exécution.
• Existe pour être modifié.
  • La modification doit être possible avec un minimum de travail.
• Communique avec la personne qui lit le code.
  • Les développeurs doivent pouvoir le lire et le comprendre facilement.

L'application de billetterie précédente satisfait la première contrainte, à savoir qu'elle s'exécute correctement, mais elle ne satisfait pas les objectifs de modifiabilité et de communication.

Code qui sort de ses gonds

Examinons pourquoi l'objectif de communication n'est pas atteint.

• Ce que fait la méthode enter() de la classe Theater
  • Le théâtre examine le sac du spectateur pour voir s'il contient une invitation.
  • Si le sac contient une invitation, il demande au vendeur de déplacer le billet qui se trouve à la billetterie dans le sac du spectateur.
  • Si le sac ne contient pas d'invitation, il retire du sac du spectateur le montant en espèces correspondant au prix du billet, achète le billet et le place dans le sac.
• Du point de vue du spectateur, il doit regarder le théâtre, une tierce partie, 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, une tierce partie, manipuler les billets et l'argent à la billetterie sans autorisation.
• Un code compréhensible est un code dont le fonctionnement ne diffère pas trop de nos attentes, et le théâtre ci-dessus ne répond pas à nos attentes.
  • Le spectateur doit retirer l'argent de son sac et le payer au vendeur pour obtenir un billet.
  • Le vendeur doit retirer le billet de la billetterie et le remettre au spectateur, puis recevoir l'argent et le placer à la billetterie.
• En outre, pour comprendre la méthode enter(), il faut se rappeler tous les détails.
  • Audience a un Bag.
  • Le Bag contient de l'argent et des billets.
  • TiketSellet vend des billets au TicketOffice, et le TicketOffice contient de l'argent et des billets.

Code vulnérable aux changements

La méthode enter() suppose deux choses.

• Le spectateur porte toujours un sac pour ranger l'argent et les invitations.
• Le vendeur vend des billets uniquement à la billetterie.

Que se passerait-il alors dans les situations suivantes ?

• Le spectateur pourrait ne pas avoir de sac.
• Le spectateur pourrait utiliser une carte de crédit au lieu d'espèces.
• Le vendeur pourrait 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. En effet, la classe Theater dépend trop du fait que le spectateur porte un sac et que le vendeur vend des billets uniquement à la billetterie. Si l'un de ces détails est modifié, il faut modifier à la fois cette classe et les classes dépendantes (par exemple, Theater).

Il s'agit d'un problème lié à la dépendance entre les objets, et la dépendance implique un impact sur les changements. Toutefois, la conception orientée objet vise à construire une communauté d'objets qui collaborent les uns avec les autres, de sorte qu'il ne faut pas supprimer les dépendances de manière aveugle, mais il fautmaintenir un minimum de dépendancesnécessaires pour implémenter les fonctionnalités de l'application et supprimer les dépendances inutiles.

Le cas où les dépendances entre les objets sont trop importantes est appeléun niveau de couplage élevé, et plus le niveau de couplage entre deux objets est élevé, plus la probabilité qu'ils soient modifiés ensemble est élevée. Par conséquent, l'objectif de la conception est de réduire le niveau de couplage entre les objets afin de créer une conception facile à modifier.

Améliorer la conception

Le théâtre n'a pas besoin de savoir que le spectateur a un sac et que le vendeur vend des billets à la billetterie. Le théâtre veut simplement que le spectateur entre dans le théâtre. Par conséquent, il faut faire en sorte que le spectateur traite lui-même l'argent et l'invitation dans son sac, et que le vendeur traite lui-même les billets et les frais de vente à la billetterie.

Augmenter l'autonomie

Un objet qui ne réalise que des tâches étroitement liées et qui délègue les tâches non liées à d'autres objets est dit avoir un niveau de cohésion élevé. La création d'objets autonomes qui gèrent eux-mêmes leurs données permet de réduire le niveau de couplage et d'augmenter le niveau de cohésion.

Orienté processus et orienté objet

• Orienté processus
  • La méthode enter() de Theater est un processus, et Audience, TicketSeller, Bag et TicketOffice sont des données.
  • La méthode de placement des processus et des données dans des modules séparés est appelée programmation orientée processus.
  • Il y a beaucoup de code qui va à l'encontre de notre intuition. (par exemple, le spectateur gère lui-même l'argent et l'invitation).
  • Il est difficile de limiter l'impact des modifications des données.
  • La responsabilité est gérée de manière centralisée. (Theater gère tout).
• Orienté objet
  • La méthode de placement des données et des processus dans le même module est appelée programmation orientée objet.
  • Il est possible d'écrire du code qui correspond à notre intuition.
  • L'impact des modifications des données peut être efficacement réduit grâce à l'encapsulation.
  • Chaque objet est responsable de lui-même.
  • 
    

Code pratique :https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Il peut être encore amélioré.

• La classe Bag de la classe Audience est toujours un objet passif qui est entraîné par la classe Audience, il faut donc faire de la classe Bag un objet autonome.
• Le TicketOffice de la classe TicketSeller est également géré à volonté par TicketSeller. Il faut faire de TicketOffice un objet autonome.
  • Toutefois, après la modification, TicketOffice a un couplage supplémentaire avec Audience.
  • Comme la conception implique un compromis, il est possible de s'entendre pour créer un objet TicketOffice relativement passif afin de réduire le couplage avec Audience.

Code pratique :https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Oui, c'est un mensonge !

• Même si quelque chose est passif dans la vie réelle, il devient un être actif et autonome lorsqu'il entre dans le monde de la programmation orientée objet.
• Il est bon d'utiliser la personnification pour considérer les objets passifs comme des objets qui rient, parlent et se fâchent.

Conception orientée objet

Pourquoi la conception est-elle nécessaire ?

• La conception consiste à placer le code.
• Une bonne conception est une conception qui satisfait pleinement les besoins d'aujourd'hui tout en acceptant les changements de demain de manière transparente.

Conception orientée objet

• Un code modifiable est un code facile à comprendre.
• Le paradigme orienté objet permet d'écrire du code de la même manière que nous voyons le monde.
• Les objets sont des entités autonomes qui sont responsables de leurs propres données.
• Une excellente conception orientée objet est une conception qui gère correctement les dépendances entre les objets qui collaborent.

Source

• Objets