Discussion :

[oodini]

Hello,

J'arrive sur un nouveau code, avec des classes énormes, et des pratiques un peu étranges.

Ainsi, je tombe souvent sur un pattern récurrent : des fonctions d'instanciation de classe, qui préparent tout un ensemble d'arguments à donner à un constructeur.
Les classes étant monstrueuses, elles ont souvent une vingtaine (ou plus) de données membres, et ça se ressent au niveau du constructeur.

Je suis sur un cas de constructeur avec 8 arguments. Il se trouve que 6 d'entre eux sont tous récupérés à partir d'un même objet.

Pseudocode illustrant ce cas :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
MaClasse buildMaClasse(const AutreClasse& other)
{
    auto a = other.getA();
    auto b = other.getB();
    ...
    auto f = foo(a,b);
    auto g = 1;
    auto h = 2.5;
 
    return MaClasse(a,b, ..., g, h);
};

La question est donc la suivante :

Faut-il remplacer les 6 arguments par un seul, à savoir other, et faire le boulot dans la liste d'initialisation de MaClasse, voire dans le corps du constructeur pour les initialisations plus complexes ?

Dans la situation actuelle, on ne passe que ce qui est nécessaire. Mais j'expose sur le site d'instanciation des détails d'implémentation de la construction de MaClasse (j'expose ce qu'utilise MaClasse pour se construire, sans que le code appelant en ait besoin par ailleurs), et je crée des dépendances.
Si je passe other, je donne potentiellement accès à un tas d'autres fonctions membre publiques. Mais après tout, si elles sont publiques, c'est de la responsabilité de MaClasse. Il faut qu'elle assume son interface.

Merci de me donner votre avis sur ce cas précis et dans le cas général.

Si vous avez envie de faire du name dropping de concepts d'architecture de code, ne vous privez pas.

[Bousk]

Salut,

le problème si tu passes other est la dépendance que tu crées.
Pour faciliter le passage d'arguments sans ajouter de dépendance, je créerais une structure intermédiaire dans la MaClasse MaClasse::Settings avec l'ensemble des champs nécessaires, et je passe cette structure seulement au constructeur.
Ainsi pas de dépendance et pas de liste à rallonge de paramètres, et ça évite la confusion de l'ordre correct des paramètres, surtout quand plusieurs du même type se suivent, puisqu'ils deviennent correctement nommés.

[Pyramidev]

Bonjour.

Pour construire un objet MaClasse à partir d'un objet AutreClasse, dans le cas où MaClasse ne stocke pas l'adresse de l'objet AutreClasse, il y a plusieurs solutions :

1. MaClasse::MaClasse(const AutreClasse&)
2. MaClasse CodeDePlusHautNiveau::buildMaClasse(const AutreClasse&)
3. MaClasse AutreClasse::buildMaClasse()

Les solutions 1 et 2 n'obligent pas AutreClasse à dépendre de MaClasse. Par contre, elles peuvent entraver l'encapsulation au niveau de AutreClasse, car cette dernière est obligée d'avoir suffisamment d'accesseurs (alias getters) pour que le code appelant récupère les informations nécessaires pour construire MaClasse.

Les solutions 2 et 3 n'obligent pas MaClasse à dépendre de AutreClasse.

La solution 2 peut obliger à créer une classe ou un espace de nom en plus (CodeDePlusHautNiveau), sauf si ce dernier existe déjà et est le seul à avoir besoin de construire un objet MaClasse à partir d'un objet AutreClasse.

Donc ça dépend du contexte. Par exemple, si MaClasse est un petit objet de configuration qui sert pour un module bas niveau et si AutreClasse est un objet de configuration volumineux qui contient des informations hétérogènes de haut niveau (ex : la configuration générale de l'application), alors j'aurais sûrement rejeté la solution 1 et j'aurais probablement choisi la solution 2.

[koala01]

Les solutions 1 et 2 n'obligent pas AutreClasse à dépendre de MaClasse. Par contre, elles peuvent entraver l'encapsulation au niveau de AutreClasse, car cette dernière est obligée d'avoir suffisamment d'accesseurs (alias getters) pour que le code appelant récupère les informations nécessaires pour construire MaClasse.

Et encore: pour ne pas *** trop *** mettre à mal l'encapsulation, une solution basée sur l'amitié (de MaClasse ou de CodeDePlusHautNiveau ) au niveau de AutreClasse peut encore être envisagée.

Cela ne crée aucune dépendance supplémentaire, vu que AutreClasse ne fait que savoir que MaClasse (ou CodeDePlusHautNiveau) existe, mais sans plus

La solution 2 peut obliger à créer une classe ou un espace de nom en plus (CodeDePlusHautNiveau), sauf si ce dernier existe déjà et est le seul à avoir besoin de construire un objet MaClasse à partir d'un objet AutreClasse.

L'un dans l'autre, c'est encore le "moindre mal", vu que ca améliore le respect du SRP. Et plus ce principe est respecté, mieux on se porte

[oodini]

Merci pour vos interventions.

Il semble donc qu'il n'y ait pas de solution unique qui se dégage.

Dans mon cas particuliers, je rajouterai que la vocation première de AutreClasse est d'être transformée en MaClasse (tout ça se trouve dans une chaîne de désérialisation)...
Il n'est donc pas du tout gênant qu'il existe un couplage fort entre les deux classes.
La relation d'amitié évoquée par koala01 semble donc assez pertinente.

En revanche, vu qu'elles sont situées dans deux modules différents, cela pose d'autres problèmes...