Discussion :

[r0d]

Bonjour,

une petite question existentielle concernant la loi de Demeter.
Imaginons que, dans notre programme, nous utilisons un objet défini et implémenté dans une bibliothèque tierce. Disons que cet objet sert à envoyer du texte à un client, nous l’appellerons Sender. Concrètement, nous ne nous préoccupons pas de savoir comme s'y prend Sender; la seule chose qui nous importe c'est que lorsqu'on appelle Sender::send( my_string ) my_string soit bien envoyée au client. Mais tout de même, Sender propose tout un tas de fonctionnalités de "tuning", comme le réglage des time_out, des fonctionnalité concernant le cryptage, etc, et au final, le protocole (ensemble de fonctions membre publiques) de Sender est assez fourni.

Afin de faciliter l'utilisation de Sender au sein de notre programme, nous décidons de l'encapsuler dans une classe à nous:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class MySender
{
public:
  // une fonction qui permet d'envoyer un tableau de string (ce que ne permet pas Sender)
  Send( const std::vector< std::string > & my_strings );
// ainsi que d'autres fonctionnalités qui ajoutent des traitements avant d'envoyer les chaines de caratères
 
private:
  Sender the_sender;
};

Mais, en plus de ces fonctionnalités, nous voudrions pouvoir utiliser directement toutes les fonctionalités de Sender. La première solution serait de faire en sorte que MySender wrappe le protocole de Sender: pour toutes les fonctions membres publiques de Sender, on implémente la même dans MySender et on appelle the_sender.the_fonction( the_parameters );

Seulement le protocole de Sender est long, et on a la flemme de tout réécrire. De plus, cela parait un travail inutile puisqu'il suffirait que MySender puisse renvoyer une référence constante sur the_sender et on utiliserait directement le protocole de Sender. Sauf que, cela va à l'encontre de la loi de Demeter.

Existe-t-il un autre solution que de redéfinir tout le protocole de Sender?

[gbdivers]

Salut

Afin de faciliter l'utilisation de Sender au sein de notre programme
(...)
nous voudrions pouvoir utiliser directement toutes les fonctionalités de Sender

C'est pas un peu contradictoire ces 2 besoins ? Si ta classe contient au moins les mêmes fonctionnalités, alors elle n'est pas plus simple.

Si l'objectif est de simplifier l'utilisation, alors ta classe est un "handler" (je sais pas s'il y a un terme spécifique), c'est à dire une classe conçu pour manipuler un autre. Elle doit alors proposer une interface simple, destiné à répondre uniquement au besoin. S'il y a plusieurs besoins, il faut plusieurs handler (respect du SRP).
Un exemple d'une telle classe, c'est stringstream, pour manipuler une string comme un flux, ou les QDataStream et QTextStream, pour manipuler QIODevice et QByteArray comme des flux.
Dans ce cas, la classe manipulée n'est pas un détail interne, mais bien une classe externe, accessible aussi au code appelant. Il n'y a pas de violation de Déméter.


Si tu as besoin d'exposer l'interface complète de Sender sans pour autant utiliser directement Sender, ni hériter publiquement de Sender (par exemple, pour contrôler les entrées et sorties de Sender), dans ce cas, c'est effectivement un wrapper et tu n'as pas d'autre choix que réimplémenter toutes les fonctions une par une (comme simple accesseur ou en ajoutant des contrôles dans les fonctions). Voir par exemple QOpenGLFunctions qui est un wrapper entre OpenGL (lib C) et Qt (lib C++). Dans ce cas, la classe Sender devient un détail interne, mais n'est pas exposée (retourner un getter permettrait d'appeller Sender sans passer par les fonctions dédiées et les contrôles), donc pas de violation de Déméter non plus

Guillaume

[r0d]

C'est pas un peu contradictoire ces 2 besoins ?

Effectivement, maintenant que tu le dis...
En fait c'est là que ma question n'est pas claire: on est entre 2 chaises. D'un côté on veut wrapper l'API, et d'un autre on veut juste l'utiliser.

[gbdivers]

2 besoins = 2 classes

[ternel]

Une autre possibilité, c'est d'utiliser des fonctions libres.

Souvent, l'interface "nouvelle" de ce type de wrapper est résumé à quelques fonctions, et aucune variable membre autre que le wrapper.

[Emmanuel Deloget]

Une petite remarque.

Soit on pense qu'on à besoin de construire une façade (parce que c'est une façade que tu propose, en encapsulant Sender), et dans ce cas la logique veut que rien de l'interface encapsulée ne soit visible par l'appelant (tu te sers de ta façade, point final). Du coup, tu est obligé de re-créer une interface de configuration de l'objet Sender sur ta façade (des objets conn_param, conn_optim, ... ?)

Soit tu penses que c'est une bonne chose d'utiliser l'objet Sender en direct, et dans ce cas, tu n'as pas besoin de façade. Tu peux juste écrire une fonction ou deux pour encapsuler certains traitements particuliers qui son communs dans l'utilisation que tu fait de l'interface de Sender.

Quoi qu'il en soit, les deux approches ne sont pas vraiment compatible