 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Olivier Croquette
Guest
|
 Posted: Mon Jan 09, 2006 6:43 pm Post subject: Limiter l'acces a une bibliotheque |
 |
|
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.
Un exemple:
class ListeChainee {
public:
void Ajouter(Elem *e) {
this->dernier->DefSuivant(e);
this->dernier = e;
this->dernier->DefSuivant(NULL);
}
}
class Elem {
public:
void DefSuivant(Elem *e) {this->suivant = e;};
}
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?
Quelles sont vos expériences?
|
|
| Back to top |
|
 |
Fabien LE LEZ
Guest
|
| Posted: Mon Jan 09, 2006 9:40 pm Post subject: Re: Limiter l'acces a une bibliotheque |
|
|
On Mon, 09 Jan 2006 19:43:15 +0100, Olivier Croquette
<ocroquette (AT) ocroquette (DOT) free.fr>:
| Quote: | 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.
| Quote: | 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".
| Quote: | 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".)
|
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Tue Jan 10, 2006 9:27 am Post subject: Re: Limiter l'acces a une bibliotheque |
|
|
Olivier Croquette wrote:
| Quote: | 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.
Un exemple:
class ListeChainee {
public:
void Ajouter(Elem *e) {
this->dernier->DefSuivant(e);
this->dernier = e;
this->dernier->DefSuivant(NULL);
}
}
class Elem {
public:
void DefSuivant(Elem *e) {this->suivant = e;};
}
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
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
