Java / Android: classes locales anonymes vs classes nommées

J’aimerais demander quelle est la bonne pratique pour utiliser des classes anonymes par rapport aux classes internes nommées?

J’écris une application Android, qui comprend de nombreux éléments de l’interface utilisateur (boutons, champs de texte, etc.). Pour beaucoup d’entre eux, j’ai besoin d’écouteurs, donc dans onCreate de l’application, j’ai un tas de petites classes anonymes comme:

 someButton.setOnClickListener( new View.OnClickListener() { public void onClick(View v) { // do something... } } );

Chacune de ces classes anonymes compte entre 5 et 20 lignes – assez petite et convient parfaitement aux recommandations de Java ™ en bref :

En général, vous devriez envisager d’utiliser une classe anonyme au lieu d’une classe locale si:
Problèmes liés à l’utilisation des derniers bocaux Square – améliorations, connexions okhttp, okio et okhttp-url
Mélange de vues Android et de GLSurfaceView
Impossible d’écrire un algorithme pour filtrer les éléments dans un RecyclerView en fonction d’un long enregistrement avec chaque élément
javax.net.ssl.SSLHandshakeException: la négociation a échoué sur Android 5.0.0 lorsque SSLv2 et SSlv3 sont désactivés (TLS uniquement) (et versions ultérieures)
Apache Commons NET: Devrais-je créer un nouvel object FTPClient sur chaque connexion ou en réutiliser un?

La classe a un corps très court.

Une seule instance de la classe est nécessaire.

La classe est utilisée juste après sa définition.

Le nom de la classe ne facilite pas la compréhension de votre code.

Mais le problème, IMO, est que onCreate devient assez volumineux et que le code devient plus complexe à lire et à comprendre en le onCreate rapidement. C’est toujours facile à comprendre, mais tout simplement trop grand.

Quelle serait donc la meilleure pratique dans ce cas – avoir un groupe de petites sous-classes internes, chacune étant bien séparée, mais utilisée une seule fois ou mieux, continue à utiliser des classes anonymes?

Je ne pense pas qu’il y ait une réponse claire d’une manière ou d’une autre. Les deux styles fonctionnent bien, c’est vraiment ce que vous préférez.

Une autre option est d’avoir

le contenu de chaque onClick par un seul appel de fonction, ce qui permet de garder les classes anonymes très courtes. C’est à dire:

 someButton.setOnClickListener( new View.OnClickListener() { public void onClick(View v) { doSomeButtonClick(); } } ); private void doSomeButtonClick() { // do something }

Refactorisez onCreate() en méthodes séparées regroupées par fonctionnalités communes afin de disposer d’unités logiques. Si l’interface graphique est complexe, cela vous aidera plus tard.

MODIFIER:

De plus, comme vous êtes par défaut davantage indenté par un formateur de code lorsque vous vous trouvez dans une classe anonyme, vos lignes doivent être plus courtes pour éviter d’être fractionnées sur plusieurs lignes par le formateur. C’est généralement ce qui indique clairement que ce serait un bon moment pour extraire la classe et lui donner un nom.

Je fais des applications de bureau / Swing, mais je pense que les concepts sont les mêmes.

Je préfère gérer tous les événements d’une classe. Je crée donc une classe de contrôleur et implémente tous les écouteurs dont j’ai besoin dans cette classe. Ensuite, je crée une méthode sur le panneau pour chaque type d’écouteur. Il ajoute l’écouteur à chaque composant du panneau qu’il doit écouter. Je passe le panneau en tant que premier argument au constructeur de la classe Controller et lui demande d’appeler chacune de ces méthodes d’ajout d’écoute sur le panneau. Ensuite, j’instancie le contrôleur lorsque j’instancie le panneau.

Cela me donne plusieurs avantages:

Tout le code de gestion d’événement est dans une classe.
Tout croisement de fonctionnalité entre événements est facilement capturé et traité.
Tout état affecté peut être stocké et contrôlé dans une classe.
Tout le code de gestion d’événement est distinct du code de disposition du composant.
La couche View (Panel) ne sait rien de la couche contrôleur.

Cela étant dit, si les événements que vous associez font tous des choses simples et que ces choses ne sont pas en conflit avec d’autres événements, il n’est pas mauvais d’utiliser des classes anonymes.

Je ne sais pas si cela est considéré par la communauté comme une pratique exemplaire, mais lorsque ce type de classe devient trop volumineux, je crée un programme d’écoute de paquet et j’y crée ma classe. Pourquoi utiliser une classe interne ou une classe anonyme si cela vous gêne ultérieurement dans votre code.

Mais la plupart du temps, si ce genre de cours devient important, c’est parce que vous n’avez pas assez délégué. Peut-être que d’autres classes devraient avoir des méthodes qui aident votre auditeur à être plus léger.

Comme le suggère la citation, c’est quelque chose de subjectif. Vous devez déterminer ce qui compte comme “très court” et “plus facile à comprendre” pour vous-même, pour déterminer à quel point la taille du code traverse la ligne de démarcation. unité.

Toute réponse que quelqu’un vous donnerait à ce sujet est basée sur ses propres mesures subjectives de ce qu’est “short” et du nombre de lignes de code qu’il faut pour ne plus être “court”.

Vous avez plusieurs avantages à placer ces éléments dans des classes nommées.

Le premier est celui que vous avez mentionné – cela rendra la méthode onCreate () plus concise et compréhensible.

La seconde est que le nom doit identifier rapidement quelle logique va avec quel bouton, ce qui fera effacer le code

La troisième est la séparation des tâches plus facile. Si vous décidez d’utiliser un modèle IoC, vous aurez beaucoup plus de facilité à injecter des implémentations nommées des écouteurs.