POO - Les objets, une histoire d'état et d'opérations

OOPOBJETSPROGRAMMATION ORIENTÉE OBJECT

Introduction
Essayons ensemble de revenir aux bases de ce qu’est un objet dans un contexte de programmation orientée objet et comment est-ce qu’ils communiquent entre eux au sein d’un programme. Pour l'écriture de cet article, je me suis intéressé à comment est-ce que le concept d'objet est introduit dans le livre SmallTalk, écrit par XXXXX.
Qu'est-ce qu'un objet ?
Un objet est constitué de propriétés privées ainsi qu’un ensemble d’opérations. Les propriétés privées sont consultables et modifiables uniquement par l’intérieur de l’objet lui-même.
Il arrive souvent qu’au sein d’un programme, on souhaite communiquer entre des objets, par exemple un objet qui représenterait un Conducteur pourrait communiquer avec un autre objet qui représenterait une Voiture. Dans ce cas on dit que l’objet Conducteur communique avec l’objet Voiture et cette communication se fait à l’aide d’un message.
Qu'est-ce qu'un message ?
Un message est une requête qu’on envoie à objet pour lui demander de réaliser une opération. Du point de vu de l’objet qui envoie le message, le détail de la réalisation(implémentation) de cette opération est abstrait dans le sens où il ne doit pas voir explicitement comment est réalisé l’opération(autrement dit, il ne doit pas voir les détails d’implémentation de l’opération demandée).
Du point de vu de l’objet qui reçoit le message, l’implémentation(les détails) de comment l’opération doit être réalisée est connue, car l’objet qui reçoit le message est responsable de la réalisation de l’opération. On peut donc distinguer deux catégories d’objets dans ce type d’intéraction(un objet qui communique avec un autre objet):
- Un appelant : Celui qui va envoyer un message dans le but de demander à un objet(recepteur) de réaliser une opération.
- Un recepteur : Celui qui va receptionner le message dans le but de réaliser une opération.
L’ensemble des messages aux quels un objet est capable de répondre(réaliser les opérations correspondentes) représente son interface. Pour communiquer avec un objet on cherchera donc à connaître avant tout son interface pour savoir quels sont les messages aux quels il pourra répondre.
Dans notre définition de ce qu’est un objet, nous avons parlé de propriétés privées. Il est essentiel de maintenir ces propriétés privées et de faire en sorte qu’elles soient manipulées uniquement lors de de l’exécution des opérations qu’effectue un objet de type récepteur.
Par exemple une opération qui permet d’augmenter la vitesse de l’objet récepteur Voiture pourrait mettre à jour cette propriété, mais un objet appelant Conducteur de l’objet récepteur Voiture ne doit pas avoir un accès direct à la propriété vitesse de l’objet Voiture.
Pourquoi est-ce que l’appelant ne doit pas connaître l’existence des propriétés privées de l’objet récepteur ?
On peut dans un premier temps dire que si on ne respecte pas cette règle, ça ne respecterait pas le principe de Tell Dont Ask qui est un principe qui aide à se rappeler que l’orientation objet a pour but de regrouper des propriétés privées ainsi que des opérations qui aggissent sur ces propriétés et qu’il vaut mieux de demander à un objet de faire quelque chose(par exemple de réaliser un calcul) afin qu’il mette à jour sa ou ses propriétés plutôt que de lire directement ses propriétés depuis un objet appelant afin de mettre à jour ses propriétés toujours depuis l’appelant.
Le principe Tell Dont Ask est un principe intéressant à suivre, car il permet d’assurer de ne pas créer de couplage entre les détails d’implémentation d’un objet recepteur et le reste du programme. On a pas envie que le fonctionnement interne de notre objet recepteur Voiture soit fortement couplé avec le fonctionnement interne de notre objet appelant Conducteur.
Pourquoi est-ce qu’on ne veut pas de couplage fort dans ce contexte (ou même de manière générale).
Une réponse des réponses possibles(je vous invite à faire des recherches pour creuser pourquoi le couplage fort peut poser des problèmes dans un programme) est qu’on ne respecterait pas le principe SRP ou on encore qu’on serait tenté de ne pas respecter le principe de la Loi de Déméter.
Nous avons éclairci ce que sont les objets dans le contexte de la programmation orienté objet et comment plusieurs objets peuvent communiquer au sein d’un programme. Nous allons voir maintenant comment faire en sorte qu’un objet puisse exister et comment est-ce qu’il fait pour recevoir des messages.
Qu'est-ce qu'une classe ?
A class describes the implementation of a set of objects that all represent the same kind of system component
Pour créer un objet, il faut dans un premier créer sa classe. Une classe est un moyen technique qui permet de décrire le comportement et l’état interne d’un objet. Grâce à la classe, on peut définir ce qu’est notre objet Voiture(à l’aide des propriétés privées) et ce que notre objet sera capable de faire (là l’aide des opérations).
Qu'est-ce qu'une methode ?
Les opérations qu’est capable de réaliser une classe sont implémentées à l’intérieur de ce qu’on appel des methodes. Ces methodes vont pouvoir faire des choses comme par exemple changer l’état interne de l’objet. L’état interne est décrit grâce aux propriétés privées qu’on appel des variables d’instances.
Une fois la classe terminée, on pourra créer ce qu’on appel des instances(les objets).
L’action de créer une instance à partir d’une classe se nomme : L’instanciation.
On peut avoir plusieurs instances d’une seule classe et toutes les instances pourront éxecuter les mêmes methodes, mais avec des variables d’instances qui ont la plus part du temps des valeurs différentes(d'une instance à l'autre)
Une histoire pour résumer ce qu’on a vu
Notre classe qui se nomme Voiture nous permet de créer une instance(objet) de classe qui a son propre état interne, qui n’est pas visible de l’exterieur.
Nous pouvons intéragir avec cette instance à l’aide de son interface en envoyant des messages(depuis l’exterieur de l’instance) qui sont connectées à des methodes(à l’interieur de l’instance).
Ces methodes vont à leur tour executer une séquence d’instruction pour réaliser une opération qui peut par exemple changer l’état interne de l’instance en affectant une nouvelle valeur à l’une de ses variables d’instance