Avant tout quelques constats :  
- Les langages objets (et d'autres également, tel Ada83) sont conçu pour pouvoir utiliser l'encapsulation, à savoir pouvoir cacher certaines parties d'un objet et ne laisser voir qu'une interface normalement bien définie.  
- Pour faire du logiciel de qualité, il faut ne laisser au programmeurs que l'accès à ce qu'ils ont besoin. En effet, sauf à utiliser des processus de développement très lourd, le programmeur aura parfois tendance à se laisser aller (et hop, un petit lien inutile, et hop, une redondance), et ces accumulations risquent de poser des problèmes de maintenance, surtout dans le cadre d'un logiciel destiné à être maintenu de nombreuses années en constante évolution.
 
Donc, pour produire du logiciel de kalitai(c), il faut utiliser au maximum les contraintes du langage pour forcer l'encapsulation, et pour garantir une bonne exploitation des contrats.  
 
La première chose à laquelle on pense est bien entendu d'utiliser le typage pour garantir la vérification à la compilation de la bonne exploitation des types passés et des appels de méthode autorisés. Cela requiert néanmoins une discipline de la part du programmeur, puisqu'il faut mieux éviter les type pas-type (Object en java, void* en C/C++) qui ont tendance à faire perdre les avantages de ce type de caractéristique. Cela demande également une grande méfiance du point de vu des cast. Mieux vaut utiliser des cast "safe", tels l'utilisation des RTTI du C++ ou une exploitation des ClassCastException en java.
 
Mais l'objet de ce post porte plutot sur l'utilisation des visibilité pour gérer au mieux cette protection. Vous savez, le truc appellé dans l'intimité PPP (Public/Protected/Private).
 
Suivant le langage, des mécanismes complémentaires sont mis en place afin de les rendre plus fine, et distinguer la visibilité au niveau classe et au niveau composant.
 
En C++, il y a le mot clef friend. Celui-ci permet à une classe de rendre visible ses membres privés à d'autres classes de son choix. Cette approche permet un réglage fin, mais me semble génante car impose à une classe de connaitre ses utilisateurs privilégié, et a tendance à tirer des lien d'un peu partout.
 
La seconde approche est celle de java, qui introduit une quatrième visibilité, appelée "Friendly" ou "Package". Cela permet de spécifier les fonctions internes à un composant de haut niveau, et ce composant est mappé sur un package. Mais cette approche donne un recouvrement des informations de namespacing et de composants, qui risque de gêner une subdivision logique de l'application en utilisant ce mécanisme, et donc d'imposer l'utilisation du namespacing à cette fin.
 
La troisième approche est celle de .NET, qui introduit des visibilité de namespace et de composants, ce qui nous donne au final plus de visibilité disponibles, ce qui abouti au fait que de nombreux programmeurs C# ne connaissent pas cette possibilité.
 
<debat>
Et vous, que pensez vous de ces remarques ? Quels sont à votre avis les bonnes façon de faire (et les mauvaises), d'autrres langages apportent-ils d'autres systèmes ?

juste un petit ajout :
Eiffel permet de rendre une fonctionnalité visible à une autre classe (un "friend" mais par fonction).
 
 
edit : cette fonctionnalité est bien entendu simulable dans les autres langages avec des types abstraits et un peu d'inventivité.

 
Un feature comme on dit en UML

Je up pour avoir d'autres avis

ben chaipas, tu veux qu'on dise quoi ?
perso j'aurais aimé un systeme me permettant de donner acces a certains membre / fonctions qu'a certaines classes (le friend du C++, en gros) sans pour autant que la classe tagée comme amie ait acces a toutes mes données private.

Dans un langage fonctionnel statiquement typé comme Ocaml, le transtypage est strictement inderdit, tous les types étant vérifiés à la compilation. De plus, par défaut, les variables ne sont pas modifiables, ce ne sont pas des variables au sens "case mémoire", mais plutôt au sens "symbole mathématique qui représente une valeur". Dans un enregistrement, il faut spécifier explicitement celles qui sont modifiables par le mot-clé "mutable".
 
Exemple (pompé sur un cours de l'X):
 
type personne = {nom : string; mutable âge : int};;
 

c'était vraiment très intéressant, domage que le rapport avec le sujet soit assez loingtain.