Je vous avais promis des aspects technologiques sur python et l’utilisation de quelques librairies intéressantes, et bien c’est loupé, initialement je voulais voir les coroutines en même temps que le décorateurs [decorateur] , mais finalement je les aies séparés. Donc nous revoilà avec un autre article sur cette petite spécificité du langage [pep-342].
Vous vous souvenez du mots clefs yield? C’est celui la que nous utilisions dans les générateurs pour produire des résultats sans interrompre le déroulement du contexte d'exécution… c'était assez magique… à bien sachez qu’il est aussi possible de lui envoyer des données en contre partie…. dur à imaginer…. effectivement…Prenons un exemple:
Affichage des articles dont le libellé est decorateur. Afficher tous les articles
Affichage des articles dont le libellé est decorateur. Afficher tous les articles
lundi 11 mars 2019
samedi 9 mars 2019
Python : Les décorateurs
Bien nous voilà maintenant encore un nouveau sujet Python, les décorateurs ! Alors promis c’est le dernier! (ou presque) parce qu'après on s'intéressera à des aspects plutôt technologique de python plutôt que des subtilités du langages…
On va donc tâcher de faire court afin de ne pas lasser!
Quoi? Vous comprenez pas? Ok faisons un parallèle avec Java… Dans Java lorsque l’on dispose d’une classe comportant certains comportement mais que ces derniers ne suffisent pas, on peut employer ce que l’on appelle un proxy [pattern-prox].
Dans le principe le proxy va prendre en paramètre l’objet que l’on souhaite décorer et s’enregistrer auprès de ce dernier afin de déclencher l’une de ses méthodes en lieu et place de l’objet en lui même. Alors bien sûr, souvent on joue quand même la méthode de l'objet mais celui ci on ajoute quelques comportement supplémentaire, on dit que l’on va décorer…
Bien en python c’est un peu la même idée mais avec des fonctions.
Ainsi un décorateur est une fonction prenant en paramètre une autre fonction (celle ci est dite décorée). Le déclarant est exécuté sur la fonction dès sa déclaration et permet donc d’agir sur celle ci.
On va donc tâcher de faire court afin de ne pas lasser!
Les décorateurs
Vous connaissez le pattern décorateur ? et bien c’est un peu la même idée sauf que dans notre cas le but est de faire plutôt comme le pattern Proxy…Quoi? Vous comprenez pas? Ok faisons un parallèle avec Java… Dans Java lorsque l’on dispose d’une classe comportant certains comportement mais que ces derniers ne suffisent pas, on peut employer ce que l’on appelle un proxy [pattern-prox].
Dans le principe le proxy va prendre en paramètre l’objet que l’on souhaite décorer et s’enregistrer auprès de ce dernier afin de déclencher l’une de ses méthodes en lieu et place de l’objet en lui même. Alors bien sûr, souvent on joue quand même la méthode de l'objet mais celui ci on ajoute quelques comportement supplémentaire, on dit que l’on va décorer…
Bien en python c’est un peu la même idée mais avec des fonctions.
Ainsi un décorateur est une fonction prenant en paramètre une autre fonction (celle ci est dite décorée). Le déclarant est exécuté sur la fonction dès sa déclaration et permet donc d’agir sur celle ci.
samedi 18 août 2018
JEE : CDI partie 2 : les patterns
Nous revoilà avec CDI, nous avions vu les principes de base de l'injection, son utilisation dans une factory et ensuite comment l'utiliser avec des servlets et des JSP. Aujourd'hui nous terminerons le sujet en traitant des implémentations de CDI des patterns observateur, décorateur (ou façade) et InvocationHandler.
Dans le framework CDI, ce pattern se traduit par l'utilisation de la classe générique Event<T> prenant en type l'information à transmettre (le vrai événement en fait) et l'annotation @Observes se chargeant de taguer le paramètre de type T d'une méthode devant recevoir l’événement, l'appel à celle ci se faisant alors automatiquement. Voyons cela dans le concret avec un exemple.
Considérons simplement que deux beans doivent communiquer entre eux (on va s'appuyer sur l'article précédent sur CDI [14]). On va considérer que CDIModelShortScope veuille prévenir CDIModel qu'une requête utilisateur vient d’être faite (en gros que l'objet vient de se creer et d'etre detruit)
On va donc modifier ce premier de façon a qu'il permette l’émission de messages en utilisant Event et en utilisant la méthode fire
On ajoute dans la classe CDIModel, le moyen d’écouter les messages:
Le comportement resultant produisant bien dans les log :
Plutôt efficace et pas cher... non? Passons au décorateur.
Regardons cela par un exemple:
Considérons un bean MyObject contenant une donnée membre "nom" de type String caracterisant l'identité de l'objet. Ce nom est recuperable via une méthode getName().
Nous souhaiterions alors une fonctionnalité nous permettant de façon transparente renvoyer le hash du nom a la place. (Par soucis de simplicité pour l'exemple on utilisera les annotations @Named et @ApplicationContext).
On va dans un premier temps proposer une solution avec un décorateur. Pour cela, il nous faut construire une classe ayant le même profil de classe que le bean décoré. On va définir une API commune sous la forme d'une interface.
Enfin définissons le décorateur: Celui se défini sous la forme d'une classe abstraite implémentant la même interface que le bean en utilisant les annotations @Delegate et @Decorator (et @Priority qui permet de donner un ordre de prise en charge des beans si plusieurs décorateurs sont a l'oeuvre sinon cela est équivalent a définir le décorateur dans le beans.xml).
Ainsi le bean prendra la forme suivante:
et le décorateur:
La JSP affichant et utilisant la méthode getName nous renverra alors:
Ce pattern est un pattern permettant de positionner un objet entre le client faisant l'appel d'une méthode et la méthode elle même. En comparaison avec le décorateur, on pourrait se dire, "ok bon ca fait la meme chose" mais l'invocation handler a plutôt pour idée de modifier le comportement de la méthode d'une classe pour toutes ses instances. Un décorateur n'a pas cet objectif : il ne va pas se charger de toutes les instances de la classe, il peut éventuellement ne décorer que des objets spécifiques selon le besoin.
On pourrait donc en quelques sortes considérer que le décorateur a pour rôle de modifier le comportement en y ajoutant des éléments fonctionnel selon le cas alors que l'invocation handler aura un impact plus global et avec une orientation plus technique.
Voyons maintenant comment utiliser l'invocation Handler avec CDI.
Pour l'exemple imaginons que nous souhaitons compter le nombre de caractère du nom de l’objet que nous utilisions précédemment et l'affecter a une donnée membre dédiée.
Pour cela il nous faut tout d'abord construire une annotation maison permettant de tisser un lien entre le bean et notre futur intercepteur. Cette annotation devra alors porter l'annotation @InterceptorBinding. Appelons la CompteurAnnot:
On place ensuite cette annotation sur la méthode du bean qu'il s'agit d'intercepter
On va enfin créer notre intercepteur avec une nouvelle classe Compteur avec les Annotations @Interceptor et @AroundInvoke. Le premier est placé sur la classe et le deuxième sur la méthode qui devra être appeler a la place de celle du bean et réaliser le comptage. On y ajoutera notre annotation, afin que CDI sache faire le lien entre l'intercepteur et le bean associé.
Du coup en ajoutant l'appel a cette méthode getSizeName dans la JSP, celle ci nous donne maintenant la taille de la chaîne, l’intercepteur a donc bien fait son travail.
[2] https://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html
[3] http://openwebbeans.apache.org/
[4] http://weld.cdi-spec.org/
[5] https://javaee.github.io/glassfish/
[6] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-decorateur.html
[7] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-observateur.html
[8] https://un-est-tout-et-tout-est-un.blogspot.com/2018/04/invocationhandler.html
[9] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-factory.html
[10] http://www.cdi-spec.org/news/2017/05/15/CDI_2_is_released/
[11] https://readlearncode.com/java-ee/introduction-to-cdi-producer-methods/
[12] https://docs.oracle.com/javaee/6/tutorial/doc/gjfzi.html
[13] https://rmannibucau.developpez.com/tutoriels/cdi/introduction-cdi
[14] http://un-est-tout-et-tout-est-un.blogspot.com/2018/08/jee-cdi-partie-1-linjection.html
Les patterns
Nous avons jusque la vu les fonctionnalités les plus importantes du framework CDI mais ca serait passer a coté d'autres fonctions bien pratiques que de s’arrêter ici. En effet comme énoncé plus haut, CDI fourni des versions adaptées à l'injection de certains designs patterns.Observateur
Voyons par exemple le pattern observateur [7] Je ne reviens pas sur ce pattern déjà décrit dans le blog mais il s'agit d'un modèle de communication réactif entre deux composants se notifiant par le biais d'un système d’événements.Dans le framework CDI, ce pattern se traduit par l'utilisation de la classe générique Event<T> prenant en type l'information à transmettre (le vrai événement en fait) et l'annotation @Observes se chargeant de taguer le paramètre de type T d'une méthode devant recevoir l’événement, l'appel à celle ci se faisant alors automatiquement. Voyons cela dans le concret avec un exemple.
Considérons simplement que deux beans doivent communiquer entre eux (on va s'appuyer sur l'article précédent sur CDI [14]). On va considérer que CDIModelShortScope veuille prévenir CDIModel qu'une requête utilisateur vient d’être faite (en gros que l'objet vient de se creer et d'etre detruit)
On va donc modifier ce premier de façon a qu'il permette l’émission de messages en utilisant Event et en utilisant la méthode fire
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | @Named @RequestScoped public class CDIModelShortScope { @Inject private Event<String> event; @PostConstruct public void build() { System.out.println("Construction de CDIModelShortScope"); event.fire("Une nouvelle conexion"); } @PreDestroy public void destroy() { System.out.println("Destruction de CDIModelShortScope"); event.fire("Fin de vie CDIModelShortScope"); } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | @Named("model") @ApplicationScoped public class CDIModel { private String dataModel="les données du model"; public void updateOnConnect(@Observes String event) { System.out.println(event); } .... } |
Le comportement resultant produisant bien dans les log :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | [#|2018-08-14T21:27:18.493+0200|INFO|glassfish 5.0||_ThreadID=27;_ThreadName=Thread-8;_TimeMillis=1534238838493;_LevelValue=800;| Construction de CDIModel|#] [#|2018-08-14T21:27:18.502+0200|INFO|glassfish 5.0||_ThreadID=27;_ThreadName=Thread-8;_TimeMillis=1534238838502;_LevelValue=800;| Construction de CDIModelShortScope|#] [#|2018-08-14T21:27:18.503+0200|INFO|glassfish 5.0||_ThreadID=27;_ThreadName=Thread-8;_TimeMillis=1534238838503;_LevelValue=800;| Une nouvelle conexion|#] [#|2018-08-14T21:27:18.505+0200|INFO|glassfish 5.0||_ThreadID=27;_ThreadName=Thread-8;_TimeMillis=1534238838505;_LevelValue=800;| Destruction de CDIModelShortScope|#] [#|2018-08-14T21:27:18.505+0200|INFO|glassfish 5.0||_ThreadID=27;_ThreadName=Thread-8;_TimeMillis=1534238838505;_LevelValue=800;| Fin de vie CDIModelShortScope|#] [#|2018-08-14T21:27:47.287+0200|INFO|glassfish 5.0||_ThreadID=132;_ThreadName=Thread-8;_TimeMillis=1534238867287;_LevelValue=800;| Destruction de CDIModel|#] |
Plutôt efficace et pas cher... non? Passons au décorateur.
Le Decorateur [6]
Je vous avais parler de pattern avec un "s" et bien CDI fourni aussi des implémentations pour quelques autres patterns, entre autre les patterns façade (ou décorateur) et invocationhandler. Ces deux patterns sont assez proche en fonctionnement, la différence étant dans la nature de la dépendance que l'on crée entre le bean décoré et l'objet décorateur ou objet intercepteur.Regardons cela par un exemple:
Considérons un bean MyObject contenant une donnée membre "nom" de type String caracterisant l'identité de l'objet. Ce nom est recuperable via une méthode getName().
Nous souhaiterions alors une fonctionnalité nous permettant de façon transparente renvoyer le hash du nom a la place. (Par soucis de simplicité pour l'exemple on utilisera les annotations @Named et @ApplicationContext).
On va dans un premier temps proposer une solution avec un décorateur. Pour cela, il nous faut construire une classe ayant le même profil de classe que le bean décoré. On va définir une API commune sous la forme d'une interface.
Enfin définissons le décorateur: Celui se défini sous la forme d'une classe abstraite implémentant la même interface que le bean en utilisant les annotations @Delegate et @Decorator (et @Priority qui permet de donner un ordre de prise en charge des beans si plusieurs décorateurs sont a l'oeuvre sinon cela est équivalent a définir le décorateur dans le beans.xml).
Ainsi le bean prendra la forme suivante:
1 2 3 4 5 6 7 8 9 10 | @Named("myObject") @ApplicationScoped public class MyObject implements INamed { private String name="defaultName"; public String getName() { return name; } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | @Priority(value = 0) @Decorator public abstract class MyObjectDecorator implements INamed{ @Inject @Delegate private INamed myObject; @Override public String getName() { return String.valueOf(myObject.getName().hashCode()); } } |
La JSP affichant et utilisant la méthode getName nous renverra alors:
1 | myObject Name: -437142420 |
L'InvocationHandler [8]
Apres avoir traité la question du décorateur regardons la solution alternative qu'est l'utilisation de l'intercepteur (basé sur le pattern invocation handler que nous avons traité dans [8]).Ce pattern est un pattern permettant de positionner un objet entre le client faisant l'appel d'une méthode et la méthode elle même. En comparaison avec le décorateur, on pourrait se dire, "ok bon ca fait la meme chose" mais l'invocation handler a plutôt pour idée de modifier le comportement de la méthode d'une classe pour toutes ses instances. Un décorateur n'a pas cet objectif : il ne va pas se charger de toutes les instances de la classe, il peut éventuellement ne décorer que des objets spécifiques selon le besoin.
On pourrait donc en quelques sortes considérer que le décorateur a pour rôle de modifier le comportement en y ajoutant des éléments fonctionnel selon le cas alors que l'invocation handler aura un impact plus global et avec une orientation plus technique.
Voyons maintenant comment utiliser l'invocation Handler avec CDI.
Pour l'exemple imaginons que nous souhaitons compter le nombre de caractère du nom de l’objet que nous utilisions précédemment et l'affecter a une donnée membre dédiée.
Pour cela il nous faut tout d'abord construire une annotation maison permettant de tisser un lien entre le bean et notre futur intercepteur. Cette annotation devra alors porter l'annotation @InterceptorBinding. Appelons la CompteurAnnot:
1 2 3 4 | @InterceptorBinding @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) public @interface CompteurAnnot {} |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | @Named("myObject") @ApplicationScoped public class MyObject implements INamed { private String name="defaultName"; private String nameSize; @CompteurAnnot public String getName() { return name; } public String getNameSize() { return nameSize; } public void setNameSize(String nameSize) { this.nameSize = nameSize; } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | @Priority(value = 0) @CompteurAnnot @Interceptor public class Compteur { @Inject private MyObject myObject; @AroundInvoke public Object invoq(InvocationContext context) throws Exception { String result = (String) context.proceed(); System.out.println("YES: on a invoqué "+result); myObject.setNameSize(String.valueOf((result.length()))); return result; } } |
1 | myObject Name: -437142420, 10 |
Conclusion
Nous voila au bout de cet article sur CDI. Nous n'avons pas absolument tout traité mais globalement on en a fait un tour d'horizon plutôt large techniquement nous permettant de suffisamment comprendre l’intérêt de profiter des fonctionnalités de CDI et surtout de voir son role pivot dans les applications à base JEE. Ainsi a l'image de Spring, CDI est maintenant un incontournable.Références
[1] https://un-est-tout-et-tout-est-un.blogspot.com/2018/05/iod-linjection-de-dependances.html[2] https://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html
[3] http://openwebbeans.apache.org/
[4] http://weld.cdi-spec.org/
[5] https://javaee.github.io/glassfish/
[6] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-decorateur.html
[7] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-observateur.html
[8] https://un-est-tout-et-tout-est-un.blogspot.com/2018/04/invocationhandler.html
[9] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-factory.html
[10] http://www.cdi-spec.org/news/2017/05/15/CDI_2_is_released/
[11] https://readlearncode.com/java-ee/introduction-to-cdi-producer-methods/
[12] https://docs.oracle.com/javaee/6/tutorial/doc/gjfzi.html
[13] https://rmannibucau.developpez.com/tutoriels/cdi/introduction-cdi
[14] http://un-est-tout-et-tout-est-un.blogspot.com/2018/08/jee-cdi-partie-1-linjection.html
dimanche 19 novembre 2017
Design pattern : Decorateur
Le pattern décorateur n'est pas forcement un pattern utilisé de façon explicite. Pourtant il se croise très souvent car il permet très proprement de compléter le comportement d'un objet en l'encapsulant dans un autre.
Généralement le décorateur est implémenté comme suit: un type abstrait est sous-typé par differentes formes de celui-ci sauf que a ces sous types, nous souhaitons leur adjoindre un comportement non systématique (c'est a dire que ce comportement doit pouvoir être mise en oeuvre a la demande). On va alors définir un nouvel ensemble de sous type de type décorateur qui ne peuvent se construire que sur un objet de son sur-type. Ainsi en répondant au service du type dont il hérite, le décorateur réalisera son comportement en même temps qu'il appellera le comportement de l’élément qu'il contient (en qu'il décore.... héhé!!)
Ceci ce traduit ainsi en diagramme de classe:
De façon assez intéressante, on pourra constater via le décorateur qu'il est possible de limiter la combinatoire du nombre de classe a réaliser en réifiant dans chaque décorateur les comportements qu'il aurait fallu dupliquer pour chaque classe C.
Par exemple:
Avec cet exemple on comprend rapidement que lors de la création des Point2D ou Point3D, si l'on souhaite leur donner une couleur, il serait dommage de les sous typer avec deux ColoredPoint2D et ColoredPoint3D alors que le décorateur permet de factoriser cette fonctionnalité.
Pour ceux qui voudront un exemple plus détaillé, je vous invite a lire cet article et enfin pour ceux qui voudront voir une application de ce pattern dans un contexte d'utilisation des lambda expression, vous pouvez lire l'article sur la DZone.
Ou consulter ce lien http://design-patterns.fr/decorateur-en-java
Généralement le décorateur est implémenté comme suit: un type abstrait est sous-typé par differentes formes de celui-ci sauf que a ces sous types, nous souhaitons leur adjoindre un comportement non systématique (c'est a dire que ce comportement doit pouvoir être mise en oeuvre a la demande). On va alors définir un nouvel ensemble de sous type de type décorateur qui ne peuvent se construire que sur un objet de son sur-type. Ainsi en répondant au service du type dont il hérite, le décorateur réalisera son comportement en même temps qu'il appellera le comportement de l’élément qu'il contient (en qu'il décore.... héhé!!)
Ceci ce traduit ainsi en diagramme de classe:
De façon assez intéressante, on pourra constater via le décorateur qu'il est possible de limiter la combinatoire du nombre de classe a réaliser en réifiant dans chaque décorateur les comportements qu'il aurait fallu dupliquer pour chaque classe C.
Par exemple:
Avec cet exemple on comprend rapidement que lors de la création des Point2D ou Point3D, si l'on souhaite leur donner une couleur, il serait dommage de les sous typer avec deux ColoredPoint2D et ColoredPoint3D alors que le décorateur permet de factoriser cette fonctionnalité.
Pour ceux qui voudront un exemple plus détaillé, je vous invite a lire cet article et enfin pour ceux qui voudront voir une application de ce pattern dans un contexte d'utilisation des lambda expression, vous pouvez lire l'article sur la DZone.
Ou consulter ce lien http://design-patterns.fr/decorateur-en-java
Inscription à :
Articles (Atom)