Une classe parent doit-elle toujours référencer les classes enfants?

Question

Bonjour,

J'ai hérité de l'ancien code au travail et il utilise un modèle de conception plutôt inhabituel. La seule référence que j'ai pu trouver sur les forums à un modèle similaire était here. La situation est que le concepteur d'origine a une classe parent générique (non abstraite) qui a une méthode factory statique qui référence directement les classes enfants.

Voici un échantillon de ce style de codage, trouvé dans plusieurs endroits dans le code existant:

public static LoggerFactory getLoggerFactory(LogType type) { 
    switch (type) { 
    case LOG4J: 
     return Log4JLoggerFactory.getInstance(); 
    case LOGBACK: 
     return LogBackLoggerFactory.getInstance(); 
    default: 
     throw new RuntimeException("No logger factory defined for type " + type); 
    } 
} 

Où s'étendent Log4JLoggerFactory et LogBackLoggerFactory LoggerFactory.

Ceci me semble vraiment étranger mais avant que je ne redimensionne le code de manière significative, y a-t-il un but ou un avantage à ce modèle de conception (y a-t-il même un nom formel)?

Des idées ou des conseils sont grandement appréciés. Merci!

EDIT: Après avoir lu la réponse de Yishai, j'ai pensé que j'inclurais un lien vers le Wikipedia article on the Strategy pattern, pour faciliter la consultation. Merci à tous pour vos réponses!

Answer 1

C'est un modèle très standard en Java, et un moyen courant d'implémenter un pattern Strategy. Vous le voyez dans l'API standard tout le temps (Calendrier vs. GregorianCalendar, NumberFormat vs. DecimalFormat et plus). Cela étant dit, avec Dependency Injection étant à la mode, un tel modèle pourrait en effet être remplacé par une classe Factory dédiée avec une interface Factory dédiée, mais en l'absence d'une plus grande raison de conception, je pense que l'exemple que vous donnez est un choix de conception parfaitement raisonnable.

Answer 2

Peut-être l'ont-ils paramétré pour utiliser Log4J dans un environnement, et Logback dans un autre? Je sais que parfois les développeurs préfèrent un outil lorsqu'ils font du développement local, mais quand vient le temps de se déployer, ils doivent utiliser tout ce que l'entreprise approuve ou approuve.

Answer 3

C'est une bonne pratique et appelé Factory Method. L'avantage est que vous renvoyez une implémentation concrète mais que vous la masquez via une interface commune ou une classe de base. Ainsi, le client n'est pas dérangé par les détails d'implémentation, mais travaille avec une classe la plus basique.

Answer 4

Que ce soit une bonne ou une mauvaise pratique, cela dépend de la situation. Par exemple, lorsque le «parent» sait comment créer tous les enfants, cela peut être une bonne pratique. Lorsque le parent ne le sait pas, cette solution ne fera que causer des problèmes.

Un autre problème est la testabilité: si le parent a beaucoup d'enfants, il peut être difficile de créer un parent isolé des enfants, mais cela dépend encore une fois.