Discussion :

[amira]

Bonjour

Dans le projet actuel un développeur écrit des interfaces avec des inner classes qu'il implémente directement et en fait des components spring. Selon lui, les classes sont trop petites (ce qui est vrai) pour avoir besoin d'une réelle classe dédiée et sont liées avec leur interface de façon très proche. Je me demande si c'est une bonne pratique, car j'avoue que j'aime l'idée mais je ne l'ai jamais vue.

Si c'est une pratique acceptée, elle a le mérite d'éviter la multiplication de petites classes avec des noms à rallonge pour des concepts très précis dans le code. Je voulais avoir votre avis.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
 
public interface InterfaceParente {
    void uneMethode();
 
 
@Component
class InnerClass1 implements InterfaceParente {
  @Override
  public void uneMethode() {
      // des actions
  }
}
 
@Component
class InnerClass2 implements InterfaceParente {
  @Override
  public void uneMethode() {
      // des actions
  }
}
 
@Component
class InnerClass3 implements InterfaceParente {
  @Override
  public void uneMethode() {
      // des actions
  }
}
}

[yildiz-online]

Je ne vais pas donner mon avis (après tout, tout le monde en a un) mais exposer une liste de pour et contre:

Pour:
- Reduit le nombre de classe.

Contre:
- Couple les implémentations et l'interface
- Refactoring compliqué dans le cas où l'interface est déplacée dans une bibliothèque séparée.
- Complique le code (est-ce que la inner classe est static ou pas vu qu'elle est dans une interface? pas clair pour tout le monde au premier coup d'oeil).
- Pratique inhabituelle, le prochain dev qui passera sur le code se demandera pourquoi on a fait comme ça et voudra tout changer.
- Depuis java 8, les inner class avec une seule fonction implementant une interface peuvent être des lambda.(java8+)
- Expose d'office l'implémentation dans un module alors que ce n'est souvent pas souhaitable(java9+)
- Disgracieux au niveau du commit history, un fichier d'interface n'est typiquement modifié que pour des nouvelles fonctionnalités ou un changement d'architecture, dans le cas présent, un bug fix l'affecterait aussi, ce qui n'est pas naturel.

[supergeoffrey]

C'est pas propre à mon avis !

Si on veut interfacer un composant c'est qu'on souhaite modifier son comportement sans modifier son contrat. La ils sont liés dans le même fichier.

Pour:
- Reduit le nombre de classe.

Plutôt réduit le nombre de fichier source Il y a deux fichiers class compilés quand même

[yildiz-online]

Plutôt réduit le nombre de fichier source Il y a deux fichiers class compilés quand même

Effectivement, merci pour la correction.

[amira]

Je ne vais pas donner mon avis (après tout, tout le monde en a un) mais exposer une liste de pour et contre:

Pour:
- Reduit le nombre de classe.

Contre:
- Couple les implémentations et l'interface
- Refactoring compliqué dans le cas où l'interface est déplacée dans une bibliothèque séparée.
- Complique le code (est-ce que la inner classe est static ou pas vu qu'elle est dans une interface? pas clair pour tout le monde au premier coup d'oeil).
- Pratique inhabituelle, le prochain dev qui passera sur le code se demandera pourquoi on a fait comme ça et voudra tout changer.
- Depuis java 8, les inner class avec une seule fonction implementant une interface peuvent être des lambda.(java8+)
- Expose d'office l'implémentation dans un module alors que ce n'est souvent pas souhaitable(java9+)
- Disgracieux au niveau du commit history, un fichier d'interface n'est typiquement modifié que pour des nouvelles fonctionnalités ou un changement d'architecture, dans le cas présent, un bug fix l'affecterait aussi, ce qui n'est pas naturel.

Je comprends ton point de vue et perso, je ne jamais vue ça non plus. A présent, ça présente aussi l'avantage de lier fortement l'interface avec la classe interne mais aussi et surtout d'éviter d'avoir des noms à rallonge (dans les projets assez techniques, on a vite des notions qui s'entrecroisent et les noms deviennent rapidement trompeurs eux-mêmes) qui a terme ne veulent plus rien dire et qui risquent là aussi de perdre le développeur.

Là, un dev qui arriverait sait que InnerClass1 appartient au domaine de "InterfaceParente".

Merci pour ta réponse !

[yildiz-online]

Justement, le couplage interface - implémentation est une mauvaise pratique car

1) le risque de dépendance cyclique est élevé
2) impossible d' utiliser l'interface sans embarquer les composants et pire, lib tierces
3) aucune encapsulation modulaire
4) pas de gestion propre des packages et responsabilités

Si la nomenclature est pourrie, c'est ca qu'il faut revoir, pas utiliser un design douteux comme cache-misère.