Hey
,
Le but de l'article est de montrer l'intérêt du modèle de conception Singleton. Son principale avantage est qu'on peut retrouver l'instance de l'objet depuis n'importe où dans le code en appelant la méthode statique
getInstance. Si on met ce mécanisme en place, c'est justement pour éviter des bidouilles qui risquent d'avoir plusieurs limitations, comme par exemple utiliser une variable en début d'application et qui contiendrait notre instance. Quand tu arrives sur des applications très lourdes avec des centaines de fichiers, voire des milliers, avoir une variable qui se balade c'est juste une aberration ! Elle peut être écrasée facilement, être remplacée etc., et j'espère que tu as des réservés de thé (ou de café … pour les autres là
) pour passer plusieurs nuits à trouver le problème. Pareil niveau maintenance, c'est impossible …
On a trouvé un modèle de conception adapté à ce genre de situation où l'on veut accéder à une donnée sans la transporter dans tout le code, ça s'appelle Singleton, et c'est plutôt pratique
.
On trouve aussi les registres qui peuvent répondre à ce problème, mais on verra plus tard
.
Dans les autres raisons conceptuelles qu'évoque Naho', je pense qu'on pourrait ajouter que si on fait du Singleton, on fait de l'objet, et que d'avoir une variable à « la racine » de l'application n'a rien d'objet … Même si tout faire en objet n'est pas toujours une solution (si si, y en a qui le disent, y sont convaincus même
), on fait au moins du fonctionnel et c'est encore plus propre qu'une bête variable (globale ou pas).
«
Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa :
http://hoa-project.net (sur
@hoaproject).
