Discussion :

[aliasjcdenton]

Bonjour à tous,

Je souhaite développer une API en Java. Cette API sera en fait un composant graphique complexe.

Il faut pour cela qu'une seule et unique classe soit accessible aux utilisateurs pour pouvoir utiliser ce composant graphique et que toutes les autres classes constituant cette API soient cachées, donc non accessibles par les utilisateurs.

J'ai bien compris l'utilité des mots clés private, protected, package-friendly et public pour le développement de mes classes et pour leurs méthodes.

Maintenant, comment faire ? Suffit-il de placer ma classe principale accessible à la racine de mon API et de placer toutes les autres classes dans un sous-package ?

Merci d'avance pour votre aide et vos explications !

[Nico02]

A partir du moment ou tu fournis une API, par définition, même si on ne peut pas les modifier, on pourra toujours accéder à tes classes d'une manière ou d'une autre.

Il faut pour cela qu'une seule et unique classe soit accessible aux utilisateurs...

Encore une fois tu fournis une API, donc ce n'est pas toi qui va décider de comment elle va être utilisée. Toutes les classes présente à l'intérieur seront 'visible' par un programmeur.

Par contre tu peux effectivement jouer sur plusieurs facteurs pour restreindre au maximum les interactions possibles avec les classes utilisateur.

1/ Jouer avec la visibilité des méthodes en utilisant au maximum les méthodes private et protected.

2/ Utiliser le mot clé final. Sur une classe cela empêchera de définir une sous classe et ainsi pouvoir potentiellement redéfinir les méthodes.
Permet de définir une constante si appliqué sur une variable.
Empêche la surcharge si appliqué sur une méthode.

3/ Utiliser des innerClass. Ces classes sont complétement invisibles pour toutes les autres classes. Par contre cela t'oblige à tout coder dans le même fichier (ce qui n'est pas très recommandé non plus, donc à utiliser avec parcimonie).

4/ Utiliser des classes abstraites. Ces classes ne sont pas instanciable.

Voila, j'ai surement oublier des choses mais ça te donne un bon point de départ.

Cdt.

[thelvin]

Euh, plus important que tout ça : à part la classe exposée, toutes les autres classes doivent être non-publiques (autrement dit package-private.)

Ainsi donc tous les autres packages n'y auront pas accès. Mais elles auront accès les unes aux autres, et la classe exposée y aura accès aussi.
Du coup elles doivent être dans le même package, bien sûr, pas dans un sous-package.

... Mais bon, à trop faire ça, on se retrouve à entasser des milliers de classes dans un seul package, c'est pas très propre. Il y a pas de mal à avoir quelques classes publiques même si elles sont dédiées à un usage interne. Il suffit de documenter correctement que rien n'est garanti, si quelqu'un s'en sert, c'est son problème, tu as jamais dit que ça marcherait.

[aliasjcdenton]

Merci pour vos réponses à tous deux !

Cela me donne des indications sur la manière de construire/ hiérarchiser mon projet.