Zend FR

Suite à une mise à jour de php je me suis retrouvé avec une fatal error due à la gestion des singletons dans ZF

si je reste à la théorie un singleton à un constructeur privé et une méthode qui permet de récupérer l'instance.

dans ce cas le singleton DOIT être une final class. car on ne peu pas dériver la classe en effet on ne poura pas utiliser de constructeur à moins de le redéfinir complètement. mais du coup on perd l'héritage du constructeur et on ne peut pas reconstruire correctement l'objet dérivé à moins de complètement recopier le constructeur parent. un comble pour de l'héritage. de plus si on fait ça un peu casser le singleton en ayant deux objet un de la classe parente l'autre de la classe fille. un singleton est normalement un objet unique et définitivement défini. donc pas dérivable. Et donc une final class.

Dans la pratique il arrive qu'on ai besoin de définir des classes de singleton que l'on puisse dériver. c'est souvent le cas d'une librairie. j'ai besoin de définir un singleton mais les utilisateurs de ma librairie vont devoir l'enrichir de leur dev pour se l'approprier. c'est en fait dans ce cas la classe fille qui est le réel singleton. dans ce cas là le constructeur ne peu plus être privé. il DOIT être protected. c'est le seul moyen qui permet d'avoir un singleton dérivé. mais il faut être prudent car on peu demander les instance de la classe mère et de toutes les classe dérivées. c'est tout de même le cas le plus courant. un bon moyen de limiter la casse mais ça ne résout rien est de faire de la classe de base une classe abstraite.

vous l'aurez compris ZF n'est ni dans un cas ni dans l'autre.

en effet dans ZF les constructeurs des singletons sont privé mais ni abstract ni final
du coup on peu les dériver mais pas obtenir d'instance (enfin plus depuis la version 5.2.6-1 de php)

si l'on prends le front contrôleur c'est un singleton mais il est particulièrement avantageux de le dériver pour capitaliser au fils des développement des applications. sans ça on recopie toujours quantités de code dans le bootstrap. mais voilà ça ne marche plus sauf à recopier le constructeur dans la classe dérivée.

existe-t-il une solution pour avoir le beurre et l'argent du beurre ?

la réponse est OUI.
la classe qui aujourd'hui dans ZF s'appelle Zend_Controller_Front devrait voir son constructeur passé en protected et devenir abstraite. donnant une nouvelle classe Zend_Controller_Abstract
l'ajour d'un nouvelle classe s'appelant Zend_Controller_Front dérivée concrète et finale ne faisant que rendre le constructeur private.

ainsi il devient impossible de dériver le Zend_Controller_Front qui est un vrai singleton comme le propose la théorie.
mais il est possible de définir son propre front contrôler en dérivant Zend_Controller_Abstract.

Cette façon de définir les singletons dans un framework apporte robustesse et evolutivité
et surtout elle clarifie la situation ne nécessitant plus de recopier du code inutilement.

A+JYT