4.1 Constructeur
Builder est un modèle de conception générative qui permet de créer un objet composite.
Sépare la construction d'un objet complexe de sa représentation afin que le même processus de construction puisse aboutir à des représentations différentes.
Forces:
- vous permet de changer la représentation interne du produit ;
- isole le code qui implémente la construction et la présentation ;
- donne un contrôle plus fin sur le processus de conception.
Côtés faibles :
- l'algorithme de création d'un objet complexe ne doit pas dépendre des parties de l'objet et de la manière dont elles s'emboîtent ;
- le processus de construction doit fournir différentes représentations de l'objet en cours de construction.
Un bon exemple est la classe HttpRequest, qui a une sous-classe HttpRequest.Builder qui peut être utilisée pour créer des instances de la classe HttpRequest et s'assurer qu'elles sont valides.
4.2 Initialisation paresseuse
L'initialisation différée est une technique de programmation lorsqu'une opération gourmande en ressources (création d'objet, calcul de valeur) est effectuée immédiatement avant que son résultat ne soit utilisé.
Ainsi, l'initialisation est effectuée "à la demande", et non à l'avance. Une idée similaire trouve une application dans divers domaines : par exemple, la compilation à la volée et le concept de logistique Just-in-Time.
Un cas particulier d'initialisation paresseuse - créer un objet au moment d'y accéder - est l'un des modèles de conception générative. Il est généralement utilisé en conjonction avec des modèles tels que Factory Method, Loner et Proxy.
Forces:
- L'initialisation n'est effectuée que lorsqu'elle est vraiment nécessaire ;
- L'initialisation initiale de l'application est accélérée : tout ce qui peut être différé est différé.
Côtés faibles :
- Il n'est pas possible de définir explicitement l'ordre dans lequel les objets sont initialisés ;
- Il y a un délai au premier accès à l'objet, ce qui peut être critique lorsqu'une autre opération gourmande en ressources est effectuée en parallèle. Pour cette raison, il est nécessaire d'examiner attentivement l'opportunité d'utiliser l'initialisation différée dans les systèmes logiciels multithreads.
Rappelez-vous comment, lors de l'écriture de web.xml, vous pouviez y spécifier l'ordre de démarrage des servlets ? C'est exactement le résultat du chargement paresseux. Tomcat créera des objets servlet la première fois qu'ils seront accédés.
4.3 Pool d'objets
Un pool d'objets est un modèle de conception parent, un ensemble d'objets initialisés et prêts à l'emploi. Lorsque le système a besoin d'un objet, il n'est pas créé, mais extrait du pool. Lorsqu'un objet n'est plus nécessaire, il n'est pas détruit mais remis dans le pool.
La mise en pool d'objets est utilisée pour améliorer les performances lorsque la création d'un objet au début d'un travail et sa destruction à la fin sont coûteuses. L'amélioration des performances est particulièrement visible lorsque des objets sont créés et détruits fréquemment, mais qu'il n'existe qu'un petit nombre d'entre eux en même temps.
Un pool d'objets est utile lorsqu'un objet possède des ressources autres que la mémoire, telles que des sockets réseau. Ou si la collection d'objets occupe une part importante de la mémoire de l'ordinateur et que beaucoup de "déchets" sont créés.
Comme vous vous en souvenez, Tomcat exécute chaque requête dans un thread séparé. Mais les threads ne sont pas créés à chaque fois, mais sont stockés dans le pool de threads. Cela permet une exécution plus rapide des requêtes : lorsqu'un thread est nécessaire, il est simplement extrait du pool. Soit dit en passant, la question est la suivante : comment placeriez-vous le thread en cours d'exécution dans le pool et le retireriez-vous du pool ?