Java : Existe-t-il un moyen de placer les classes imbriquées dans un fichier séparé ?

Question

J'ai une classe Java d'environ 4 000 lignes (beaucoup de méthodes). Cette classe utilise ensuite environ 200 petites classes dont elle seule a besoin, soit 4 000 lignes de code supplémentaires.

Si c'était du C#, je mettrais ces autres classes dans un fichier de classe partielle donc différent, mais elles resteraient des classes privées imbriquées uniquement visibles par la classe parente.

Existe-t-il un moyen de faire cela en Java ? Je ne demande pas que certaines méthodes soient dans un fichier distinct, mais que les classes privées imbriquées soient dans un fichier distinct.

merci - dave

Answer 1

Vous ne pouvez pas rendre une classe privée pour une autre classe seulement en la plaçant dans un fichier différent.

N'utiliser aucun modificateur d'accès à la classe

Ce que vous pouvez faire, c'est placer les classes dans des fichiers séparés sans modificateur d'accès (omettre "public"), ce qui les rendra "package-private", c'est-à-dire visibles uniquement dans leur propre paquetage. Voir aussi le tutoriel officiel sur le contrôle d'accès .

UtilClasses.java :

package OurPackage;

class UtilClass1
{
}
class UtilClass2
{
}

MainClass.java :

package OurPackage;

public class MainClass
{
   UtilClass1 iAmAUtilClass;
}

---

Utiliser des interfaces ou l'héritage

Vous pouvez également obtenir quelque chose de similaire avec les interfaces ou l'héritage, en omettant le modificateur d'accès de la classe imbriquée. Il s'agirait également d'un package-private, mais cela pourrait être préférable à ce qui précède dans certaines circonstances, car cela évite d'avoir toutes les classes imbriquées au niveau supérieur.

BaseInterface.java :

package OurPackage;

interface BaseInterface
{
   class UtilClass1
   {
   }
}

MainClass.java :

package OurPackage;

public class MainClass implements BaseInterface
{
   UtilClass1 iAmAUtilClass;
}

Vous pouvez également utiliser une classe de base au lieu d'une interface et l'étendre avec à peu près le même effet.

Vous n'avez pas besoin de mettre en œuvre BaseInterface d'accéder à ses classes imbriquées, mais, si vous ne le faites pas, vous devrez utiliser BaseClass.UtilClass1 au lieu de simplement UtilClass1 .

Answer 2

Les classes privées internes ne peuvent pas être "extraites" et rester visibles uniquement pour une classe particulière. Une solution est déjà mentionnée dans les commentaires : Créez un package qui contient la classe "main" et toutes les classes internes précédentes et rendez le package des classes internes visible. Cela vous permettrait également de créer des tests unitaires pour tester les fonctionnalités correctes des classes internes, ce qui n'est probablement pas le cas actuellement, simplement parce que les classes internes ne peuvent pas être "atteintes" par un test unitaire pour le moment.

Des concepts tels que la déclaration d'"amitiés" entre classes comme en C++ n'existent pas en Java.

Answer 3

Vous pouvez remplacer les classes internes par des classes de niveau supérieur, mais vous devrez réécrire à la main un grand nombre de choses que le compilateur crée automatiquement pour vous avec la relation entre les classes internes. Pour la machine virtuelle, une classe interne n'a rien de spécial, c'est juste une autre classe dans le même paquet que la classe externe avec un nom fantaisiste. Mais le compilateur crée un grand nombre de constructions d'aide sous le capot, que vous devez reconstruire à la main (ou demander à un outil de refactoring de le faire pour vous) :

• La classe interne peut faire référence à la classe externe this en le préfixant avec le nom de la classe externe. Vous devez passer le nom de la classe externe this dans votre constructeur interne et le stocker dans un champ tel que outerThis pour y accéder.
• Dans le code source, vous pouvez appeler directement les méthodes de la classe externe. Vous devez le réécrire comme outerThis.method() . T
• Pour que les méthodes et les champs externes privés deviennent accessibles, le compilateur crée des constructions de pont pour vous. Vous devez soit modifier les modificateurs d'accès, soit créer vous-même des méthodes-ponts privées par paquet.

Au final, les anciennes classes internes seront au moins visibles du paquetage et seront plus verbeuses que les classes originales, mais d'un autre côté, vous obtiendrez une meilleure isolation et une meilleure testabilité.