Décorateurs : classes et interfaces implémentées

[JabX]

Aujourd'hui, on peut renseigner implements ou extends dans une implémentation de décorateur. Il n'y a presque aucune règle de gestion associée à ce qu'on met ici (à l'exception d'un contrôle qui vérifie qu'on ne met pas plusieurs extends sur une classe), alors qu'en réalité, il y a plein de besoins derrière :

Interfaces

• Un décorateur est souvent utilisé pour définir une interface qu'une classe doit implémenter, et le décorateur liste les propriétés de l'interface. Parfois, cette interface provient d'une librairie externe, donc c'est OK, mais parfois il s'agit d'une classe interne au projet, et donc il faut que le développeur écrive cette interface à la main alors qu'il l'a déjà écrite dans TopModel.
  => Comment faire pour la générer ?

• Un décorateur avec une interface peut implémenter un autre décorateur avec une autre interface qui est implémentée par l'interface du premier décorateur. Par conséquent, le code généré implémente les deux interfaces alors que seule celle portée par le deuxième décorateur est utile.
  => Comment faire pour indiquer que la deuxième interface implémente la première ?

Classes

• Les classes ont les mêmes problèmes que les interfaces (à la différence près que le deuxième point est bloquant puisqu'on ne peut pas étendre plusieurs interfaces)

• Dans le cas où la classe n'est pas dans le modèle, on ne peut pas intégrer les propriétés de cette classe dans le modèle, puisque les propriétés écrites dans le décorateur ferait doublon dans le code généré.
  => Comment faire pour ne pas générer certaines propriétés dans le code ?

Evidemment, on gère des classes abstraites déjà dans le modèle qui ont l'air d'entre en collision avec ce qu'on pourrait faire ici (et qui n'ont rien à voir...)...

La résolution du problème devra certainement passer par une explicitation des cas d'usages des décorateurs, en particulier sur le fait qu'ils représentent un objet externe au modèle (qui est le cas actuel), ou un vrai objet du modèle (potentiellement à générer, ce qu'on ne gère pas/gère très mal). Peut être encore un autre objet (hybride classe décorateur ?) 😁

Du coup une idée serait de revoir abstract: true sur les classes pour remplacer par type: abstract/interface(/normal), avec les interfaces générées comme les classes abstraites aujourd'hui, type: abstract généré comme comme une abstract class (enfin !), et surtout donner la possibilité à d'autres classes de pouvoir implémenter ces classes là comme des décorateurs (en particulier donc, pas extends).