Je viens de commencer à développer en Java après ne pas l'avoir touché depuis mes études. Jusqu'à présent, j'ai pu me souvenir de beaucoup de choses et lire tout un tas, celui-ci n'est toujours pas clair pour moi ...De C++/C# vers Java - Corriger correctement le code avec la règle "un type public par classe"
Le problème que j'ai est que beaucoup de livres/exemples/tutoriels/Les messages SE se concentrent sur des problèmes plus simples et plus petits où ce type de question ne se produirait pas.
Si vous avez un projet avec 1000 de types (classes, interfaces ou les deux) ... est la meilleure structure de projet/convention de mise en page pour créer simplement un nouveau fichier pour chaque type? Venant de l'arrière-plan C++/C#, cela ne me convient pas (encore?) Car j'ai l'habitude d'avoir typiquement un, ou peut-être peu de fichiers qui définiraient les interfaces utilisées dans le reste du projet. Et de petites classes liées seraient souvent implémentées dans un seul fichier.
À titre d'exemple plus concret, je suis actuellement en train de refactoriser une classe "Event" qui gère actuellement 15 types d'événements différents, le tout dans une classe. Le package dans lequel la classe est définie contient également d'autres classes de gestion d'événements, telles que des lecteurs, des auteurs et des analyseurs.
Si je crée classe d'événements de base et 15 classes dérivées, comme chacun a des attributs/comportements légèrement différents ... ce sont mes options:
- 15 nouveaux fichiers au package existant tout ajouté - semble que je '' polluerait '' ce paquet comme le nombre de fichiers passerait de 6 à 21 et l'orthogonalité casserait.
- Déplacez toutes les classes d'événements dans leur propre package et conservez-les ensemble
- Créez un fichier, appelé "Events.java" et placez les 15 classes comme des classes statiques imbriquées de cette classe principale (par exemple, "class Events" devenir juste un espace de noms) - semble que Google fait cela avec leurs tampons de protocole. Ayant pas assez d'expérience Java, je ne peux pas décider quelle approche est une norme acceptée.
Est-il correct d'avoir 1000 de fichiers dans un répertoire? Devrais-je créer plus de paquets? (en regardant d'autres bibliothèques/frameworks, il semble qu'ils gardent le nombre de paquets au minimum)
Dans d'autres cas, en particulier lors de l'implémentation d'un modèle de stratégie, je créerais une classe de base publique avec une méthode d'usine statique et un nombre des classes non publiques juste pour que je puisse les conserver dans un seul fichier. On dirait que je fais ces choix de "design" uniquement sur la base de cette règle de type public par classe et que tout le temps que je fais ça, cette question revient ... peut-être que je ne fais pas les choses correctement.
Vos classes ne doivent pas être public, vous pouvez les garder privées, par exemple. En outre, si votre ensemble d'événements est fixe, vous pouvez envisager d'utiliser un 'enum'. – fge
J'ai une centaine de classes parce que j'ai utilisé un modèle de commande. Ce nombre de classes ne devient un problème que si elles sont trop différentes les unes des autres. Je plaiderais certainement contre la création de classes internes; la seule bonne raison de créer des classes internes est quand elles sont vraiment liées aux (détails d'implémentation de la classe externe). Astuce: utilisez un fichier 'pacakge-info.java' pour décrire le contenu du paquet dans son JavaDoc, et indiquez les classes les plus importantes pour vos utilisateurs (y compris celles visant à étendre les fonctionnalités). –