ajout la clé PGP d’un serveur debian non reconnu:
gpg –keyserver hkp://wwwkeys.eu.pgp.net –recv-keys XXX
où XXX correspond aux 8 derniers caractères de la clé à rechercher
puis
gpg –armor –export XXX | apt-key add -
Les différentes versions Java / J2EE & co
=====================================================
J2EE
=====================================================
Java EE 5
* Servlet 2.5
* JSF 1.2
* JSP 2.1
* EJB 3.0
J2EE 1.4
* Servlet 2.4
* JSF 1.1
* JSP 2.0
* EJB 2.1
=====================================================
TOMCAT
=====================================================
tomcat 5.5
* Servlet 2.4
* JSP 2.0
tomcat 5.0
* Servlet 2.4
* JSP 2.0
tomcat 4.x
* Servlet 2.3
* JSP 1.2
=====================================================
STRUTS
=====================================================
Struts 1.3.x
* Servlet 2.3
* JSP 1.2
=====================================================
JSTL
=====================================================
JSTL 1.1
* Servlet 2.4
* JSP 2.0
JSTL 1.0
* Servlet 2.3
* JSP 1.2
Le design pattern décorateur permet d’ajout de nouvelles fonctionnalités à une classe sans en modifier le code: il s’agit de créer une nouvelle classe enrobant la classe existante et ainsi offrir ses fonctionnalité de base tout en y ajoutant de nouvelle fonctionnalités.
La classe décoratrice possède une instance de la classe décorée comme attribut. Cette instance peut être soit créée par le décorateur lui même, soit passée en paramètre au constructeur de la classe.
Si la classe de base peut être modifiée, il est intéressant d’en extraire une interface afin de rendre le décorateur non plus lié à une classe mais à une interface. Dans ce cas, la classe décoratrice pourra être déclarée comme implémentant l’interface.
L’intérêt du design pattern “Visiteur” est de séparer un algorithme des données qu’il traite. Les données traitées doivent être stockées dans des classes possédant une méthode
public void accept(Visitor v)
On peut par le même occasion définir une interface Visitable définissant cette méthode et implémenter cette interface dans toutes les classes de données.
Visitor est une interface possédant une méthode visit() pour chaque classe de données. Cette méthode est appelée par la méthode accept de chaque classe de données. Le code des méthodes accept est donc toujours le même:
public void accept(Visitor v){
v.visit(this);
}
Coder l’algorithme revient à créer une ou des classes implémentant l’interface Visitor et de définir le comportement de l’algorithme pour chaque classe de données.
Ci dessous le diagramme de classes UML d’un exemple simple d’utilisation du design pattern Visiteur
Le design pattern Visiteur peut s’avérer très pratique dès qu’il s’agit de gérer des arborescences d’objets, puisque dans ce cas il permet aussi de spécifier la manière dont les relations entre les objets doivent être parcourues. Le cas d’un algorithme de génération de code à partir d’un arbre sémantique en mémoire est un bon exemple. L’arbre sémantique du code à générer est représenté en mémoire par un arbre d’objets. Chaque élément de l’arbre est un objet d’une classe implémentant l’interface Visitable. En plus d’appeler la méthode adaquat du visiteur, la méthode accept d’un noeud de l’arbre va appeler la méthode accept de tous ces enfants dans l’ordre qui lui convient et ainsi faire avancer le parcours de l’arbre. L’objet Visiteur est ainsi propagé dans tous les éléments de l’arbre.
Le design pattern visiteur est un exemple de design pattern de délégation.
Propulsé par WordPress