J'ai un problème qui doit être classique, et j'essaie de trouver les
solutions tout aussi classiques!
Soit une bibliothèque écrite en C++, assez importante, et par conséquent
divisée en de nombreuses classes et fichiers.
Les classes s'utilisent les unes les autres. Certaines méthodes sont
publiques pour qu'elles soient accessibles par d'autres classes, mais je
voudrais qu'elles ne soient pas accessibles pour l'utilisateur de la
bibliothèque.
DefSuivant() est publique pour qu'elle puisse être appelée par
Ajouter(), mais dans le concept de la bibliothèque, elle ne devrait être
appelée que par Ajouter(), et pas par l'utilisateur de la bibliothèque.
J'apperçois quelques solutions:
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça
deviennent difficilement gérable à la longue
2) espaces de nom: y a-t'il une solution convaincante?
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il
ne peut pas
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On Mon, 09 Jan 2006 19:43:15 +0100, Olivier Croquette :
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça deviennent difficilement gérable à la longue
Effectivement. Il est possible de bricoler un proxy pour que seule telle classe ait accès à telle fonction de telle autre classe, mais c'est lourd et pas forcément élégant.
L'autre solution est de cacher des classes (cf idiome "pimpl", appelé aussi "compilation firewall"), ou au moins de les déclarer comme membres privés d'autres classes.
L'idée est de faire en sorte que le header de ta bibliothèque soit réduit aux classes et fonctions auxquelles l'utilisateur doit avoir accès ; tout le reste va dans des headers privés, ou même des .cpp.
De même, utilise, quand c'est possible, des fonctions libres au lieu de fonctions membres : elles n'ont pas besoin d'être déclarées dans le header public.
2) espaces de nom: y a-t'il une solution convaincante?
Tu veux parler des namespaces, j'imagine ? La réponse me paraît négative : contrairement aux classes, les namespaces n'ont pas de notion de "membres privés".
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il ne peut pas
Éventuellement.
Dans certains de mes headers, il y a des passages intitulés "Cuisine interne", que l'utilisateur n'a pas le droit de lire. (En fait, il s'agit principalement de la définition de fonctions templates -- mon compilo ne supporte pas "export".)
On Mon, 09 Jan 2006 19:43:15 +0100, Olivier Croquette
<ocroquette@ocroquette.free.fr>:
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça
deviennent difficilement gérable à la longue
Effectivement.
Il est possible de bricoler un proxy pour que seule telle classe ait
accès à telle fonction de telle autre classe, mais c'est lourd et pas
forcément élégant.
L'autre solution est de cacher des classes (cf idiome "pimpl", appelé
aussi "compilation firewall"), ou au moins de les déclarer comme
membres privés d'autres classes.
L'idée est de faire en sorte que le header de ta bibliothèque soit
réduit aux classes et fonctions auxquelles l'utilisateur doit avoir
accès ; tout le reste va dans des headers privés, ou même des .cpp.
De même, utilise, quand c'est possible, des fonctions libres au lieu
de fonctions membres : elles n'ont pas besoin d'être déclarées dans le
header public.
2) espaces de nom: y a-t'il une solution convaincante?
Tu veux parler des namespaces, j'imagine ?
La réponse me paraît négative : contrairement aux classes, les
namespaces n'ont pas de notion de "membres privés".
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il
ne peut pas
Éventuellement.
Dans certains de mes headers, il y a des passages intitulés "Cuisine
interne", que l'utilisateur n'a pas le droit de lire. (En fait, il
s'agit principalement de la définition de fonctions templates -- mon
compilo ne supporte pas "export".)
On Mon, 09 Jan 2006 19:43:15 +0100, Olivier Croquette :
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça deviennent difficilement gérable à la longue
Effectivement. Il est possible de bricoler un proxy pour que seule telle classe ait accès à telle fonction de telle autre classe, mais c'est lourd et pas forcément élégant.
L'autre solution est de cacher des classes (cf idiome "pimpl", appelé aussi "compilation firewall"), ou au moins de les déclarer comme membres privés d'autres classes.
L'idée est de faire en sorte que le header de ta bibliothèque soit réduit aux classes et fonctions auxquelles l'utilisateur doit avoir accès ; tout le reste va dans des headers privés, ou même des .cpp.
De même, utilise, quand c'est possible, des fonctions libres au lieu de fonctions membres : elles n'ont pas besoin d'être déclarées dans le header public.
2) espaces de nom: y a-t'il une solution convaincante?
Tu veux parler des namespaces, j'imagine ? La réponse me paraît négative : contrairement aux classes, les namespaces n'ont pas de notion de "membres privés".
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il ne peut pas
Éventuellement.
Dans certains de mes headers, il y a des passages intitulés "Cuisine interne", que l'utilisateur n'a pas le droit de lire. (En fait, il s'agit principalement de la définition de fonctions templates -- mon compilo ne supporte pas "export".)
kanze
Olivier Croquette wrote:
J'ai un problème qui doit être classique, et j'essaie de trouver les solutions tout aussi classiques!
Soit une bibliothèque écrite en C++, assez importante, et par conséquent divisée en de nombreuses classes et fichiers.
Les classes s'utilisent les unes les autres. Certaines méthodes sont publiques pour qu'elles soient accessibles par d'autres classes, mais je voudrais qu'elles ne soient pas accessibles pour l'utilisateur de la bibliothèque.
DefSuivant() est publique pour qu'elle puisse être appelée par Ajouter(), mais dans le concept de la bibliothèque, elle ne devrait être appelée que par Ajouter(), et pas par l'utilisateur de la bibliothèque.
J'apperçois quelques solutions:
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça deviennent difficilement gérable à la longue
2) espaces de nom: y a-t'il une solution convaincante?
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il ne peut pas
4) autre?
Créer des classes de proxy pour l'interface, avec seulement des opérations que tu veux permettre aux utilisateurs de la bibliothèque. Ne fournir les en-têtes que de ces classes-là.
Formellement, évidemment, on n'empèche rien. Mais sans les en-têtes, il faut vraiment le vouloir pour y accéder.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Olivier Croquette wrote:
J'ai un problème qui doit être classique, et j'essaie de
trouver les solutions tout aussi classiques!
Soit une bibliothèque écrite en C++, assez importante, et par
conséquent divisée en de nombreuses classes et fichiers.
Les classes s'utilisent les unes les autres. Certaines
méthodes sont publiques pour qu'elles soient accessibles par
d'autres classes, mais je voudrais qu'elles ne soient pas
accessibles pour l'utilisateur de la bibliothèque.
DefSuivant() est publique pour qu'elle puisse être appelée par
Ajouter(), mais dans le concept de la bibliothèque, elle ne
devrait être appelée que par Ajouter(), et pas par
l'utilisateur de la bibliothèque.
J'apperçois quelques solutions:
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça
deviennent difficilement gérable à la longue
2) espaces de nom: y a-t'il une solution convaincante?
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il
ne peut pas
4) autre?
Créer des classes de proxy pour l'interface, avec seulement des
opérations que tu veux permettre aux utilisateurs de la
bibliothèque. Ne fournir les en-têtes que de ces classes-là.
Formellement, évidemment, on n'empèche rien. Mais sans les
en-têtes, il faut vraiment le vouloir pour y accéder.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'ai un problème qui doit être classique, et j'essaie de trouver les solutions tout aussi classiques!
Soit une bibliothèque écrite en C++, assez importante, et par conséquent divisée en de nombreuses classes et fichiers.
Les classes s'utilisent les unes les autres. Certaines méthodes sont publiques pour qu'elles soient accessibles par d'autres classes, mais je voudrais qu'elles ne soient pas accessibles pour l'utilisateur de la bibliothèque.
DefSuivant() est publique pour qu'elle puisse être appelée par Ajouter(), mais dans le concept de la bibliothèque, elle ne devrait être appelée que par Ajouter(), et pas par l'utilisateur de la bibliothèque.
J'apperçois quelques solutions:
1) "friend": j'ai peur qu'avec déjà quelques dizaines de classes, ça deviennent difficilement gérable à la longue
2) espaces de nom: y a-t'il une solution convaincante?
3) simplement documenter ce que l'utilisateur peut appeler et ce qu'il ne peut pas
4) autre?
Créer des classes de proxy pour l'interface, avec seulement des opérations que tu veux permettre aux utilisateurs de la bibliothèque. Ne fournir les en-têtes que de ces classes-là.
Formellement, évidemment, on n'empèche rien. Mais sans les en-têtes, il faut vraiment le vouloir pour y accéder.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
