2010-09-03 7 views
2

Je vous écris un arbre B-link et ses sous-classes auxiliaires comme une classe de page de données et une classe de noeud, etc.Est-il possible en C++ de rendre l'interface d'une classe privée à toutes les classes sauf quelques unes?

Je me demandais est-il un moyen de protéger les interfaces publiques des noeuds et des pages telles que seulement la classe d'arbre b-link elle-même peut y accéder, SANS exposer simultanément les méthodes privées des pages et des noeuds à la classe b-link? J'ai déjà pensé à simplement changer l'interface 'publique' des pages et des noeuds dans la catégorie protégée, puis à déclarer l'arbre B-link comme un ami mais à donner à l'arbre b-link l'accès à des méthodes privées Je veux rester privé.

Répondre

6

Du haut de ma tête, vous pourriez faire quelque chose comme:

class FooAdapter; 

class Foo 
{ 
private: 
    void funcToExpose(); 
    void funcToHide(); 
    friend FooAdapter; 
}; 

class FooAdapter 
{ 
private: 
    Foo foo; 
    void funcToExpose() { foo.funcToExpose(); } 

    friend SomeFriend; 
}; 

(compilé ou non testé, mais vous devriez obtenir l'idée.)

+1

+1. Vous pouvez également utiliser un modèle similaire en utilisant l'héritage pour les amis "virtuels". – Puppy

+0

@DeadMG: Pourriez-vous élaborer? –

+1

Si vous êtes un ami de la classe de base, il peut alors implémenter des méthodes qui enveloppent efficacement les méthodes prévues - permettant aux classes dérivées d'y accéder comme si elles étaient des amis. – Puppy

0

Si vous ne voulez pas les interfaces des nœuds et des pages à exposer dans votre API puis déclarez-les simplement dans votre fichier d'implémentation de b-link. Si l'implémentation b-link couvre plus d'un fichier, placez les déclarations de noeud et de classe de page dans un fichier d'en-tête de mise en œuvre (co-localisé avec vos fichiers d'implémentation, et non avec vos en-têtes API).

2

Vous pouvez essayer de définir vos sous-classes auxiliaires dans un espace de noms anonyme dans la même unité de traduction que l'arborescence b-tree. Supposément cela rendra ces clases inaccessibles de l'extérieur de cette unité de traduction.

Voir Unnamed/anonymous namespaces vs. static functions

+0

Cette idée est intéressante mais je ne pense pas qu'elle fonctionnerait correctement. La logique dans les noeuds et les pages est assez lourde pour qu'ils aient leurs propres fichiers .cpp, ce qui rend leur mise dans un espace de noms sans nom dans le fichier BLinkTree assez difficile. –

+0

'# inclure 'vos fichiers d'implémentation dans l'espace de noms anonyme – gpeche