[Objet] Chapitre 2. Programmation orientée objet

Système de réservation de billets de cinéma

Examen des exigences

• Nous souhaitons mettre en œuvre un système de réservation de billets de cinéma en ligne.
• Un film représente les informations de base sur un film.
  • Titre, durée de projection, informations sur le prix, etc.
• Une projection représente l'événement réel pendant lequel le public regarde un film.
  • Date de projection, heure, numéro de séquence, etc.
• Les gens disent qu'ils réservent des films, mais en réalité, ils devraient dire qu'ils réservent un film spécifique qui est projeté. C'est la façon la plus correcte de le dire.
• Conditions de réduction
  • Possibilité de réduction sur le prix
  • Condition d'ordre : utiliser le numéro de séquence de projection pour déterminer l'éligibilité à la réduction
  • Condition de période : utiliser l'heure de début de projection du film pour déterminer l'éligibilité à la réduction
• Politique de réduction
  • Déterminer le tarif réduit
  • Politique de réduction de montant : appliquer une réduction fixe sur le prix de réservation
  • Politique de réduction en pourcentage : appliquer une réduction d'un certain pourcentage sur le prix normal
• Un film peut avoir une politique de réduction qui lui est attribuée ou ne pas en avoir du tout, et plusieurs conditions de réduction peuvent être combinées.
• Si une politique de réduction est appliquée mais que les conditions de réduction ne sont pas remplies, ou si aucune politique de réduction n'est appliquée, le prix n'est pas réduit.

Vers la programmation orientée objet

Collaboration, objets, classes

• L'orienté objet consiste à s'orienter vers les objets.
  • Ne vous inquiétez pas des attributs et des méthodes dont une classe a besoin après avoir décidé de la classe.
  • Vous devez déterminer quels objets ont quel état et quel comportement.
  • Les objets doivent être considérés non pas comme des entités indépendantes, mais comme des membres d'une communauté qui coopère.

Structure de programme qui suit la structure du domaine

• Le domaine fait référence au domaine dans lequel l'utilisateur utilise le programme pour résoudre un problème.

<span class="image-inline ck-widget" contenteditable="false"><img src="https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fe7d22a03-4a24-40e9-8068-bd03b9fd816b%2FUntitled.png?table=block&id=3f1931fc-8ef9-470a-8189-3727146638f6&spaceId=b453bd85-cb15-44b5-bf2e-580aeda8074e&width=2000&userId=80352c12-65a4-4562-9a36-2179ed0dfffb&cache=v2" alt="Untitled" style="aspect-ratio:2000/438;" width="2000" height="438"></span>

• En général, le nom d'une classe doit être identique ou du moins similaire au nom du concept de domaine correspondant.
• La relation entre les classes doit également être aussi similaire que possible à la relation entre les concepts de domaine afin de faciliter la compréhension et la prédiction de la structure du programme.

Implémentation de la classe

• Une classe est divisée en interne et en externe, et pour concevoir une bonne classe, vous devez décider quelles parties rendre publiques et quelles parties masquer.
  • Les attributs d'un objet sont masqués en privé et les méthodes nécessaires pour modifier l'état interne sont ouvertes en public.
• La distinction entre l'intérieur et l'extérieur d'une classe garantit l'autonomie de l'objet, ce qui offre au programmeur la liberté d'implémentation.

Objet autonome

• Un objet doit être un objet autonome ayant un état et un comportement.
• Le regroupement des données et des fonctions à l'intérieur d'un objet est appelé encapsulation.
• Le contrôle d'accès doit être utilisé pour réduire les interférences externes afin que l'objet puisse décider de ses propres actions.
• Le principe de séparation de l'interface et de l'implémentation est un principe essentiel à respecter pour la programmation orientée objet.
  • Interface publique : partie accessible de l'extérieur
  • Implémentation : partie accessible uniquement de l'intérieur

Liberté du programmeur

• Le rôle du programmeur est divisé entre le créateur de classe et le programmeur client.
  • Le créateur de classe ajoute un nouveau type de données
  • Le programmeur client utilise le type de données ajouté par le créateur de classe
• Masquage de l'implémentation
  • Le créateur de classe peut masquer l'implémentation interne en fournissant uniquement les parties nécessaires au programmeur client.
  • Le programmeur client n'a besoin de connaître que l'interface, ce qui réduit la quantité de connaissances nécessaires.

Communauté d'objets collaboratifs

• Lors de la représentation de l'argent, il est préférable d'emballer l'argent dans un objet, comme Money, plutôt que de simplement déclarer une variable de type Long. L'utilisation d'objets permet une meilleure communication du sens et permet d'effectuer des opérations redondantes à un seul endroit.
• L'interaction entre les objets pour implémenter une fonctionnalité du système est appelée collaboration.

Une courte histoire sur la collaboration

• La seule façon pour un objet d'interagir avec un autre objet est d'envoyer ou de recevoir des messages.
• La méthode propre à chaque objet pour traiter les messages reçus est appelée méthode.
• Il est important de distinguer les messages des méthodes, et c'est là que commence le concept de polymorphisme.

Calcul du tarif réduit

Démarrer la collaboration pour le calcul du tarif réduit

• La classe Movie ne contient pas la logique détaillée de la politique de réduction, mais la délègue à l'interface DiscountPolicy. L'utilisation de l'héritage, du polymorphisme et de l'abstraction est vraiment importante.

Politique de réduction et conditions de réduction

<span class="image-inline ck-widget" contenteditable="false"><img src="https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F7b9b27a5-0dac-4ba7-9552-05b7f8fbdecd%2FUntitled.png?table=block&id=3264f189-6e12-4a55-94d2-75b851320c7a&spaceId=b453bd85-cb15-44b5-bf2e-580aeda8074e&width=2000&userId=80352c12-65a4-4562-9a36-2179ed0dfffb&cache=v2" alt="Untitled" style="aspect-ratio:2000/535;" width="2000" height="535"></span>

Héritage et polymorphisme

Dépendance au moment de la compilation et dépendance au moment de l'exécution

• La dépendance du code et la dépendance au moment de l'exécution peuvent être différentes.
• Plus la dépendance entre les deux est différente, plus le code est difficile à comprendre, mais plus il est flexible et extensible.

Programmation par différence

• L'héritage permet d'ajouter facilement et rapidement de nouvelles classes sur la base de classes existantes et de réutiliser l'implémentation de la classe parente.
• La méthode consistant à créer une nouvelle classe en ajoutant uniquement les parties différentes de la classe parente est appelée programmation par différence.

Héritage et interface

• L'héritage permet à la classe enfant d'hériter de toutes les interfaces fournies par la classe parente.
• Une interface définit la liste des messages qu'un objet peut comprendre.

• Movie envoie le message calculateDiscountAmount à DiscountPolicy. Du point de vue de Movie, il n'a pas d'importance quelle instance de classe répond, tant qu'elle fournit une réponse avec succès.
• Par conséquent, AmountDiscountPolicy et PercentDiscountPolicy peuvent tous deux collaborer avec Movie à la place de DiscountPolicy.
• Ce remplacement d'une classe enfant par sa classe parente est appelé conversion ascendante. En effet, il semble que la classe enfant soit automatiquement convertie en classe parente située au-dessus.

Polymorphisme

• Le polymorphisme est la capacité d'un objet à répondre différemment à un même message en fonction de son type.
  • Movie envoie le même message, mais la méthode qui sera réellement exécutée dépend de la classe de l'objet qui reçoit le message.
• Le polymorphisme est basé sur le fait que la dépendance au moment de la compilation et la dépendance au moment de l'exécution d'un programme peuvent être différentes.
• Le polymorphisme détermine la méthode à exécuter au moment de l'exécution, il est donc appelé liaison différée ou liaison dynamique.

Interface et polymorphisme

• Si vous ne souhaitez pas partager l'implémentation mais uniquement l'interface, vous pouvez utiliser une interface au lieu d'une classe abstraite.

Abstraction et flexibilité

Le pouvoir de l'abstraction

• Avantages de l'abstraction
  • Si vous examinez uniquement la hiérarchie d'abstraction, vous pouvez décrire la politique des exigences à un niveau élevé.
  • La conception devient plus flexible.

Conception flexible

• L'abstraction empêche la conception d'être liée à des situations spécifiques, ce qui permet de créer une conception flexible.

Compromis entre classe abstraite et interface

• Actuellement, NoneDiscountPolicy n'est pas vraiment nécessaire car la méthode calculateDiscountAmount() de DiscountPolicy renvoie 0 s'il n'y a pas de condition de réduction, donc il n'y a pas de problème. Cependant, du point de vue de l'utilisateur, il faut ajouter une politique None sans réduction comme paramètre de Movie, donc nous l'avons ajouté.
• Par conséquent, la classe NoneDiscountPolicy est déroutante conceptuellement, donc la modifier comme suit la rend plus facile à comprendre.

• Comme indiqué ci-dessus, l'idée est de rendre DiscountPolicy abstrait en tant qu'interface et de le diviser en NoneDiscountPolicy, qui est une implémentation, et DefaultDiscountPolicy, qui représente une politique de réduction générale.

<span class="image-inline ck-widget" contenteditable="false"><img src="https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F712983a9-3937-4265-82fe-66a144c44a0f%2FUntitled.png?table=block&id=f5ca651c-d03c-4a6c-97e9-7443ee5649a0&spaceId=b453bd85-cb15-44b5-bf2e-580aeda8074e&width=2000&userId=80352c12-65a4-4562-9a36-2179ed0dfffb&cache=v2" alt="Untitled" style="aspect-ratio:2000/886;" width="2000" height="886"></span>

• On pourrait penser que l'ajout d'une interface uniquement pour NoneDiscountPolicy est inefficace par rapport à la complexité accrue.
• Il faut être conscient que tout ce qui concerne l'implémentation peut faire l'objet d'un compromis et concevoir en conséquence. En d'autres termes, tout code que vous écrivez doit avoir une raison valable.

Réutilisation du code

• L'héritage peut être utilisé pour réutiliser du code.
• Cependant, pour la réutilisation du code, il est préférable d'utiliser la composition plutôt que l'héritage.
• Dans le code actuel, la façon dont Movie réutilise le code de DiscountPolicy est la composition.
• Si nous prenions Movie comme classe parente et la divisions en AmountDiscountMovie et PercentDiscountMovie, nous aurions utilisé l'héritage.

Héritage

• Inconvénients de l'héritage
  • Viole l'encapsulation.
    • Vous devez bien connaître la structure interne de la classe parente.
    • Lors de la modification de la classe parente, la classe enfant est également susceptible d'être modifiée.
  • Rend la conception moins flexible.
    • La relation entre la classe parente et la classe enfant est déterminée au moment de la compilation.
    • Il est impossible de modifier le type d'objet au moment de l'exécution.
    • Cependant, avec la composition, le côté qui utilise peut remplacer l'instance au moment de l'exécution via une méthode telle que changeDiscountPolicy().

Composition

• La méthode de réutilisation du code uniquement via les messages définis dans l'interface est appelée composition.
• Elle permet de mettre en œuvre l'encapsulation et de maintenir un couplage lâche.
• Lors de la réutilisation d'une interface pour le polymorphisme, l'héritage et la composition doivent être combinés.
  • Par exemple, l'interface DiscountPolicy doit nécessairement utiliser l'héritage pour implémenter ses implémentations inférieures.

Source

• Objet