[MVC] Utilisez-vous la méthode init() des contrôleurs d'action ? [Débat]

[Yogui]

Salut

Un débat vient de naître sur les listes de Zend Framework : faut-il utiliser __construct() ou bien init() dans un contrôleur d'action ? Pourquoi l'un plutôt que l'autre ?

La réponse apportée par la majorité des participants est favorable à init(). Cependant, cette méthode est déclarée avec une visibilité "public", ce qui n'a pas d'intérêt puisqu'elle est systématiquement appelée depuis le contrôleur lui-même.

Il a donc été suggéré de la rendre protected dans une version ultérieure.

Si la méthode Zend_Controller_Action::init() devient protected, elle deva être renommée en _init().


En parallèle, Lars Strojny est intervenu pour déconseiller l'existence d'une méthode init(), argumentant que cette méthode a le même objectif que __construct()...

Hi Matthew,

Am Samstag, den 12.07.2008, 14:55 -0400 schrieb Matthew Weier O'Phinney:
> -- Hector Virgen <djvirgen@gmail.com> wrote
> (on Saturday, 12 July 2008, 10:41 AM -0700):
> > If Zend_Form::init() becomes protected, will it be renamed to _init()?
>
> Yes -- but such a change will not happen prior to 2.0 at the earliest,
> if at all.


I have to admit that I find the wide-spread usage of init()-methods
quite unfortunate, as they address a bad programming habit. Not calling
the parent constructor is a bad practice, as it will always break code.
I totally agree that complicated setup code do not belong in the
constructor itself, but the init()-methods are not about complicated
object setups but about allowing the user to forget about
parent::__construct(). So I would really love to see most of them go
away in 2.0.

cu, Lars

Qu'en dites-vous ?

[MaitrePylos]

Personnellement; je trouve qu'une méthode doit-être utilisée que si elle apporte quelque chose de confortable et un réel +.

dans le cas du init(), cette méthode apporte-elle quelques choses de plus.

Si la réponse est non, alors __construct() devrais-être utilisé en priorité.

[Yogui]

Ok, prenons le problème par l'autre bout.

Actullement, la méthode __construct() des contrôleurs est réservée par le framework lui-même. En tant que développeur utilisant le framework, il nous est déconseillé d'utiliser __construct() à cause de sa complexité. Nous avons donc à notre disposition init(), une méthode appelée tout à la fin de __construct(), ce qui revient donc au même.

Si je définis un contrôleur d'actions My_Controller_Action dérivé de Zend_Controller_Action et qui me sert de base pour tous mes propres contrôleurs d'action, j'utilise la méthode init() comme constructeur.

Par extension, lorsque je définis un contrôleur d'action final dans mon appli, quelle méthode dois-je utiliser pour personnaliser à nouveau le constructeur ? __construct() n'est plus accessible et init() est déjà utilisé. Dois-je surcharger init() en appelant parent::init() ? En ce cas, pourquoi ne pas le faire avec __construct() ? Par souci d'homogénéité, je pourrais donc déclarer un niveau supplémentaire de constructeur : mettons setup()... Ce qui me donne trois méthodes pour la même opération.

C'est sans doute cela que Lars voulait mettre en avant.

[MaitrePylos]

En même temps, pour récupérer l'objet ancêtre de __construct et en hériter, tu dois appeler parent::__construct.

tu ne dois donc pas redéfinir, ni surcharger cette méthode, sauf si tu veux modifier explicitement cette méthode.

Idem pour init();

[Alexandre T]

Je me suis souvent demandé pourquoi init() n'était pas une méthode protégée. J'y vois un seul argument, un développeur n'ose pas vraiment surcharger une classe protégée d'un framework. Techniquement parlant, il est plus logique qu'elle soit protégée.

Utiliser le constructeur ou utiliser une fonction d'initialisation a toujours été un débat dans la programmation orienté objet. J'hésite même à parler de troll.