Design Pattern : Singleton
Dans la série des questions d'entretien, et des choses utiles, je vais passez en revue les design pattern les plus courants et les plus utiles. Alors commençons tout d'abord par le Singleton : Ce design pattern, ou Patron de conception, permet de créer une et une seule instance d'une classe et de renvoyer, quand une classe tiers demande une nouvelle instance, toujours la même. Il permet à plusieurs programme de tous partager la même instance d'une classe. Le meilleur exemple d'utilisation restant la connection à une base de donnée. Car au sein d'une application on ne va jamais ouvrir plusieurs connection, par contre chaque programme qui exécute des requêtes aura besoin de récupérer le connection. D'où la solution suivante souvent utilisée d'un Singleton DbConnectionManager :
// récupérer la connection :
DbConnectionManager.getInstance().getConnection();
L'implémentation d'un singleton est simple, il suffit de définir le constructeur comme privé, et de conserver une variable static représentant l'instance à renvoyer de notre classe :
public class Singleton {
private static Singleton instance;
private Singleton() { /* Do nothing... */ }
public static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
}
Voilà comment créer un singleton, et factoriser les accès à une ressource. Quand le singleton est utilisé dans un contexte multi-thread, il est nécessaire que la méthode getInstance soit synchronized (Verrou d'exclusion mutuelle) pour que lors de l'appel simultané à cette méthode de deux processus léger, l'un créer une nouvelle instance (si inexistante) et l'autre se récupère la première et unique instance.
Newsletter
Stay updated with new articles.
Keep reading
Design Pattern : Proxy
Continuons un peu notre tour d'horizon avec le design pattern Proxy. Un proxy est, de par la nature du mot, souvent une interface entre plusieurs composants, servant de pont entre ceux-ci. Avec un Pro...
Oct 30, 2009Modélisation de la C.A.F par des Threads asynchrones
Sur une idée originale de [Divarvel](http://www.eklablog.com/ "Eklablog by Divarvel & co"), qui a un jour twitté que le meilleur exemple pour décrire les Threads asynchrones était la C.A.F... et surto...
Jul 17, 2009
Le paradoxe de l'analyste programmeur ?
Je trouve que ce comic illustre bien le coté scientifique de ce travail ainsi que son absence de reconnaissance. Car au fond la seule mission déclarée du programmeur se résume à **"Make it work"** peu...
Nov 18, 2009
No comments yet. Be the first to comment!