Discussion :

[metagoto]

Bonjour,

Admettons qu'on ait une classe A qui a une sémantique de valeur (value semantic). Pas de destructeur virtuel, pas fait pour être dérivé.

Un certain nombre d’opérations doivent agir sur les instances de A et nécessitent d'accéder aux membres privés.
On va naturellement penser à ajouter des méthodes à cette classe:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct A { // exemple fictif
  //.. ctors, assignment ops etc
 
  int method1(); // série de méthodes publiques
  int method2();
  int method3();
  //..
private:
  int i, j;
};
 
// utilisation 
A a;
a.method1();
a.method2();

Problème: Parce que A est vraiment utile (penser au type int, même si j’exagère rassurez-vous) et qu'il y a toujours plus de méthodes à ajouter (car potentiellement intéressantes), on se retrouve avec une classe dont l'interface publique est disproportionnée.

Solution: Tailler dans les méthodes et passer par des fonctions libres. Idéalement ces fonctions sont chargées à la demande par l'utilisateur (des fichiers de header distincts).

Problème: Quid de l’accès aux membres privés?

Question: Quels design, technique, idiome adopteriez-vous afin de remédier à ce problème? Si tant est que le problème fut le bon..

[Trademark]

Salut,

Difficile de répondre sans avoir de contexte. C'est peut-être le moment pour toi de faire du refactoring ? Il se peut que tu ais rajouté des responsabilités à ta classe au fur et à mesure des besoins. Donc en gros il faut peut-être revoir les services qu'offrent ta classe et délégué ceux de plus bas niveau dans d'autres classes qu'utilisera la classe A.

Sinon c'est vrai que la question : "Quand utiliser une fonction libre plutôt qu'une méthode ?" est assez intéressante. En tout cas, si cette fonction libre doit utiliser des membres privés de la classe, il faut vraiment avoir une bonne raison de ne pas vouloir en faire une méthode (comme le make_shared_ptr qui est obligatoirement une fonction libre pour des raisons de construction de l'objet).

[metagoto]

La classe en question fait partie d'une librairie "json". Plus particulièrement il s'agit du type principal qui encapsule des valeurs json-esques (bool, int, double, array...). C'est un pur toy project en c++11.

Code :

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

1
2
val a = 1; // initialisé avec un int
a = {true, 3.14, "hello"}; // a est maintenant un "array"

Beaucoup d’opérations sont possibles sur les objects val comme par exemple rapatrier la valeur, faire des queries ou conversion, itérer si le type le permet etc.

Il est clair que je veux passer par des fonctions libres. Diverses fonctionnalités ne sont pas forcement toujours utiles. Il me semble idiot de blinder la classe val (qui est en fait un basic_val paramétré par un trait) avec trop de méthodes.

Code :

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

1
2
get<string>(a) vs a.get<string>()
keys(a) vs a.keys() // quand a est un "objet"

Ma question initiale (1er post) est purement technique.

[Joel F]

les interfaces a bases de fonctions libres sont plus facilement extensibles pour des types que tu ne controle pas (paradigme #1 de la programmation générique)

[koala01]

Salut,

De manière générale, une fonction membre devrait correspondre à un service que tu es en droit d'attendre de la part de ton objet, alors qu'une fonction libre te permettra d'avantage d'utiliser ces services dans un ordre donné afin d'obtenir un résultat prévisible.

Qu'il s'agisse d'une classe ayant sémantique d'entité ou d'une classe ayant sémantique de valeur ne changera pas grand chose à partir du moment où la responsabilité de ta classe est clairement établie et "suffisamment simple" pour lui permettre d'être utilisée en étant cohérente avec le but pour lequel elle a été développée.

A priori, si la responsabilité d'une classe est clairement établie, les cas dans lesquels tu te trouveras face à l'obligation de rajouter une fonction membre devraient être particulièrement limités dans le sens où, s'il est toujours possible de se rendre compte que l'on a oublié de permettre à la classe de rendre un service donné (Mince, j'avais oublié de considérer le fait qu'il est sans doute utile qu'un compte en banque puisse indiquer son solde" ) cela découle directement de la responsabilité que l'on a donné à la classe.

D'un autre coté, une fonction libre a l'énorme avantage de permettre à un type donné d'interagir avec des données extérieures sans rajouter de dépendances entre le type envisagé et le type de données avec lequel on veut le faire interagir.

La liste de dépendances d'une classe est en effet composée de, cela va de soi, tous les types de données qu'elle manipule pour son usage interne, mais, aussi, de tous les types de données que l'on peut envisager de lui passer en argument.

Plus tu rajouteras de fonctions membres nécessitant des paramètres de types différents, plus tu rajouteras des dépendances à ta classe alors qu'elle n'en a, sans doute, pas forcément besoin pour faire son travail.

C'est d'autant plus dommage que ces dépendances sont, naturellement, satisfaites au niveau de "ce qui utilise" ta classe et la donnée avec laquelle la mettre en relation

L'idée générale est donc qu'il faudrait avoir vraiment une bonne raison pour rajouter une fonction membre plutôt qu'une fonction libre