Ajout de fonctionnalités: sous-classe vs décorateur

Question

Je travaille actuellement sur un système hérité utilisant l'implémentation ADF Faces JSF d'Oracle pour la couche de présentation. Le système s'appuie sur un moteur de règles pour rendre certains éléments de formulaire obligatoires, désactivés ou même mis en surbrillance en fonction de l'interaction de l'utilisateur avec eux ou des valeurs entrées.

Au stade actuel, l'application fonctionne, en quelque sorte. La mise en œuvre actuelle manipulation du moteur de règles et les mises à jour de l'extrémité avant est pas très élégante et se compose d'un grand nombre de cas des déclarations similaires à:

if(screenObj instanceof CoreInputText) { 
    ((CoreInputText) screenObj).setDisabled(true); 
} 

Pour compliquer le mélange, nous avons aussi nos propres objets mélangés dans de sorte que le mettre dans son ensemble ne partage pas un ancêtre commun éliminant ainsi notre possibilité de faire quelque chose comme:

((CommonAncestor) screenObj).setDisabled(true); 

la question est de savoir si oui ou non il serait utile de retravailler cette partie du code pour être plus propre et plus claire. Étant donné que la majorité des éléments de l'écran sont des éléments Faces ADF, nous ne sommes pas en mesure/autorisés à modifier leur ascendance pour ajouter des méthodes supplémentaires. Le but du changement de code serait double: nettoyer le code ancien et améliorer la base de code de sorte que l'ajout de nouveaux éléments ou contrôles n'entraîne pas de changement de code important (en particulier pour les instructions if qui existent dans de nombreux endroits). Donc, si nous allons de l'avant avec ce changement, qui serait le meilleur choix pour atteindre ce que nous recherchons? Sous-classe de tous les éléments (nécessitant une nouvelle classe chaque fois que nous utilisons un autre contrôle préexistant) ou implémentation du motif décorateur? Ma seule préoccupation avec le décorateur est qu'il faudrait toujours un changement de code pour chaque élément supplémentaire. Les deux options semblent réduire les changements de code puisque plusieurs méthodes contenant ces blocs if n'ont pas besoin d'être mises à jour. Toute contribution sur les méthodes pour gérer de telles situations au-delà de la sous-classification et des décorateurs est la bienvenue!

Answer 1

Bien qu'ils n'aient pas d'ancêtre commun, vous ne spécifiez pas s'ils ont une méthode commune. Si c'est le cas, alors peut-être simplement mettre une interface à l'exécution en utilisant un proxy qui appelle simplement la méthode afin que vous ayez un type commun. C'est une sorte de décorateur, certainement, et comme il utilise la réflexion, il peut être trop lent (mais probablement pas) mais il a l'avantage que tout nouvel objet ayant juste à implémenter la bonne signature de méthode interface, et réserver le Proxy pour les anciens objets et créer conditionnellement le proxy dans une méthode d'usine qui vérifie si l'objet en a besoin).

De plus, si c'est un vrai setter, vous pouvez utiliser BeanUtils d'apache et le définir comme une propriété appelée disabled. EDIT: Étant donné qu'ils n'ont pas la même méthode, du code devra être ajouté chaque fois que vous ajoutez un nouvel objet, sauf si vous pouvez au moins contrôler que les nouveaux objets auront une interface définie . Cela étant dit, si vous êtes à l'aise en descendant la route de réflexion, vous pouvez créer une carte de classes de méthodes (à condition que les méthodes prennent un booléen - et vous pouvez même forcer votre chemin si vous devez) et rechercher l'objet sur la carte. Ainsi, lorsque vous introduisez un nouvel objet, vous n'avez qu'à ajouter une entrée dans la carte. Cependant, je préférerais éviter cela, car cela semble aller trop loin dans la réflexion. Cela rend les noms de méthodes très difficiles à refactoriser, et impossible pour un IDE de comprendre qu'ils sont utilisés dans ce contexte.Je pense que le décorateur est le bon choix à première vue car, abstraction faite de toute autre considération, la composition devrait être préférée à l'héritage et cela rendra le code plus clair quant à ce qui se passe, améliorant ainsi la maintenance à long terme.