- Java ne supporte pas l'héritage multiple, ce qui rend impossible l'utilisation d'un autre objet de base qu'Action.
- la classe Action ne fournit à l'implémenteur aucun service utile. Il n'y a pas en effet de méthodes de cette classe qui soient utilisées par les implémenteurs d'Actions struts pour se faciliter la vie. C'est dommage, car une classe de base est, dans le modèle théorisé qui est le mien, un ensemble fonctionnel (ou quasi-fonctionnel) que l'implémenteur d'une classe dérivée pourra utiliser facilement.
Or la classe Action ne fournit pas de services, mais un contrat, ce qui est très différent. En tant que contrat exprimé, elle devrait, en théorie, être une interface, ce qui permettrait aux codeurs d'applications web de l'utiliser à leur gré, et donc de définir réellement leur contrôleur.
Et comme la classe Action est réellement le coeur de Struts, son mauvais codage fait, de ce point de vue, de Struts un mauvais framework.
[^] # Re: Struts or not ?
Posté par Nicolas Delsaux . En réponse à la dépêche Conception et déploiement J2EE - Critique du livre. Évalué à 3.
- Java ne supporte pas l'héritage multiple, ce qui rend impossible l'utilisation d'un autre objet de base qu'Action.
- la classe Action ne fournit à l'implémenteur aucun service utile. Il n'y a pas en effet de méthodes de cette classe qui soient utilisées par les implémenteurs d'Actions struts pour se faciliter la vie. C'est dommage, car une classe de base est, dans le modèle théorisé qui est le mien, un ensemble fonctionnel (ou quasi-fonctionnel) que l'implémenteur d'une classe dérivée pourra utiliser facilement.
Or la classe Action ne fournit pas de services, mais un contrat, ce qui est très différent. En tant que contrat exprimé, elle devrait, en théorie, être une interface, ce qui permettrait aux codeurs d'applications web de l'utiliser à leur gré, et donc de définir réellement leur contrôleur.
Et comme la classe Action est réellement le coeur de Struts, son mauvais codage fait, de ce point de vue, de Struts un mauvais framework.