Je en suis pas C++ien, mais Dotnetien, mais le principe s’applique à toute programmation objet.

Le concept expose le principe (en résumé très rapide) de ne pas exposer les variables d’une classe permettant ainsi un éventuel traitement extérieur, mais au contraire d’intégrer dans la classe, les méthodes de traitements de ces variables, masquant, si possibles les dites variables.

Hors il n’est pas toujours possible/judicieux de masquer les variables en questions. Il n’est pas toujours possible de définir exhaustivement tous les traitements qui pourraient être appliquer à ces variables afin d’en intégrer les méthodes correspondantes dans la classe.

Le cas de la classe de configuration est un bon exemple. Cette classe gérant l’accès/sauvegarde de la configuration du logiciel, son but est donc de lire et d’écrire la configuration sur le support de sauvegarde (méthodes) mais aussi de mettre à disposition du reste du programme les paramètres ainsi lus (accesseurs).
Prennent l’exemple d’une chaine de connexion à un SGBD. Ce paramètre n’a pas vocation à être utilisé directement (et uniquement) dans la classe de configuration. Et pourtant ce paramètre peut amener (sous Dotnet en tout cas) à changer de type.
Cela voudrait dire que les méthodes utilisant cette chaine de connexion, c’est à dire des méthodes d’accès aux données, devraient être dans la classe configuration ? Personnellement, je pense qu’elles n’ont rien à y faire.

Autre point :
La modification du type d’un accesseur, plus généralement d’une surface d’exposition d’une classe (c’est valable aussi pour les types de retour des méthodes), constitue une cassure dans la compatibilité de la classe. Certes cela doit être éviter au maximum et représente bien souvent une mauvaise conception au départ.
Mais lorsque cela est impossible à éviter, cela traduit une évolution majeure bien trop importante pour pouvoir assurer la compatibilité tant au niveau de la classe, qu’au niveau du code l’utilisant.
Je en trouve pas choquant dans ce cas là, que tout le code utilisant cette classe doit être repris, ne serait-ce que pour contrôler d’éventuels effets de bord.

Je suis d’accord que le concept exposé ici, est une « bonne pratique » que l’on devrait essayer d’appliquer le plus souvent possible, mais il ne faut pas non plus en faire sa quête du Graal, car il ne faut pas voir le voir comme un concept universel et polyvalent.

Prenons le cas suivant réel suivant,
La classe A est un ensemble de paramètres de l’application.
La classe B est une dialogue permettant l’édition des paramètres de A.

Comment faire pour permettre l’édition de ces paramètres sans que le type de chaque paramètre soit connu par la classe B?

Je me suis posé les mêmes questions, c’est pour cela que j’ai fait un projet de test pour voir ce qu’il en était en pratique.
Comme vous pouvez le voir dans le code, il faut :

• que l’émetteur dérive de QObject (pour les méta informations) ;
• que l’émetteur possède la macro Q_OBJECT (cela permet au moc de reconnaître le signal) ;
• pour la connexion avec des pointeurs de fonctions uniquement, il faut que le récepteur hérite de QObject.

Donc on a besoin du moc dans tous les cas et de dériver de QObject pour les pointeurs de fonctions. Par contre, les fonctions lambdas sont plus permissives et peuvent s’utiliser avec n’importe quelle classe/fonction en réception.

Mais la question que je me pose est : Y a-t-il encore besoin de moc, ou serait-il possible d’avoir une chaîne de compilation plus classique.