POO & Design Patterns

Rappels POO

L'encapsulation en un dessin

Le code extérieur n'utilise que les méthodes publiques !

Pour voir comment cela se traduit en Java et en Python, il faut cliquer sur la flèche du bas.

Visibilité en Java

Java offre plusieurs niveaux de visibilité :

  • private qui n'est visible qu'à l'intérieur de la classe.
  • public qui est visible à l'extérieur de la classe.
  • default/package (souvent appelée visibilité package-private) qui n'est visible que depuis une classe appartenant au même package.
  • protected qui est visible par la classe et les classes qui en hérite. Cette visibilité peut conduire à une portée d'accès trop large pour notre usage car les classes qui hérient peuvent se trouver dans d'autres packages. Comme nous n'utiliserons l'héritage que comme une solution locale de factorisation du code, nous n'utiliserons pas cette visibilité.

Les indications de visibilité sont là pour aider/guider les utilisateurs de votre code, mais il est toujours possible de passer outre en utilisant la réflexion.

Niveau de visibilité en Python

Python n'offre pas de notion de visibilité aussi explicite et aussi fine qu'en Java.

Cependant on peut définir une méthode ou un champ comme privé en préfixant son nom par deux underscores.

L'interpréteur Python renommera la méthode ou le champ pour le cacher de l'utilisateur mais il est toujours possible d'y accéder.

Rappels: encapsulation (1/3)

Un objet définit:

  • un intérieur = état = ces champs (privés),
  • un extérieur = les autres objets.

Les méthodes publiques d'un objet définissent son contrat avec le monde extérieur. Les autres objets sont ses clients et ses méthodes publiques sont les services qu'il offre.

Attention, en POO, on parle d'interface plutôt que de contrat mais ce n'est pas nécessairement une interface au sens Java du terme.

Rappels: encapsulation (2/3)

Les objets clients ou utilisateurs d'un objet ne se basent que sur son contrat/interface, pas sur comment il est implémenté. Si l'on change, le contrat d'un objet tous ses clients sont impactés.
⇛ Il faut bien réfléchir avant de rajouter une méthode au contrat/interface d'une objet.

Rappels: encapsulation (3/3)

L'objet est le seul responsable de la cohérence de son état.

Le constructeur est le point d'entrée pour la création de l'objet:

  • Il n'effectue que des initialisations (création de l'état) et des vérifications (garantie de cohérence).
  • Si on a besoin de faire des calculs compliqués pour construire un objet, on délègue le travail à une méthode ou à un autre objet (cf. les design patterns Builder et Factory).

Les méthodes publiques doivent maintenir la cohérence de l'état:
⇛ Attention aux getters et aux setters !!!!

Immutabilité

Un objet immutable si son état ne peut plus être modifié après la construction.

Pour un objet immutable, il n'y a pas de problème de cohérence de l'état.
En particulier, aucun problème de concurrence !
⇛ Quand c'est possible, c'est un plus.

Si l'immutabilité est si bien, pourquoi ne pas rendre tous les objets immutables!

Problème de performance : tout changement implique de recréer complètement un nouvel objet.

Visibilité pour les packages et les librairies

  • Les notions de visibilité et de contract sont aussi valables pour les packages et pour les librairies.
  • Dans le monde pro, une méthode publique dans une classe ou une librairie, c'est un engagment à vie.

SOLID--

  • un concept = une classe
    protocole avec 200 trames = 200 classes/records
  • une classe = un seul rôle
  • avoir les contrats pour les librairies, les plus simples et les plus proches du besoin