Dans de nombreux thèmes que je l' ai vu (y compris TwentyEleven) et dans les exemples que j'ai trouvé en ligne, lors de la construction du functions.php
fichier pour un thème toutes les fonctionnalités est déclarée dans une portée globale. Pour clarifier, voici à quoi ressemble un fichier de fonctions typique:
function my_theme_do_foo() { // ... }
function my_theme_do_bar() { // ... }
add_action( 'foo_hook', 'my_theme_do_foo' );
Il me semble que les choses pourraient être "encapsulées" un peu mieux si une classe était utilisée:
class MyTheme {
function do_foo() { // ... }
function do_bar() { // ... }
}
$my_theme = new MyTheme();
add_action( 'foo_hook', array( &$my_theme, 'do_foo' ) );
Les avantages de la seconde approche (à mes humbles yeux):
- Noms de fonctions plus courts
- Accès aux variables d'instance (le plus grand avantage de l'OMI)
- Pas de fonctions globales
Les désavantages:
- Le nom de classe peut toujours provoquer des conflits
- Pas aussi clair pour "personnaliser" avec un thème enfant (il faudrait étendre une classe parent)
- La plupart des thèmes ne l'ont pas fait de cette façon, donc vous contrarieriez la tendance
J'oublie probablement certaines choses, mais je me demande pourquoi ne pas adopter l'approche POO? Cela me semble un peu "plus propre", si quelque chose. Peut-être que je me trompe?
Je suis assez nouveau dans le développement de thèmes WordPress, alors pardonnez-moi si c'est une connaissance courante dans la communauté WP :). J'essaie juste d'apprendre pourquoi les choses sont comme elles sont.
la source
Réponses:
L'utilisation d'une classe pour l'encapsulation est une approche très courante par un certain nombre de développeurs pour les plugins. Je le fais et je le trouve plus propre. Mais pour les plugins. Les thèmes sont de nature plus procédurale.
Nous ne le faisons pas pour les thèmes WordPress par défaut, car cela soulève la barrière à l'entrée. Les fonctions sont assez simples. La suppression des actions liées aux classes peut être difficile (et potentiellement boguée dans des circonstances spécifiques).
De plus, un certain nombre de fonctions des thèmes par défaut sont enfichables. Étendre une classe et remplacer les méthodes est beaucoup plus compliqué que de simplement définir la fonction. Et bien que deux aspects différents du code puissent remplacer différentes fonctions, vous ne pouvez pas étendre dynamiquement des classes. Comme vous l'avez souligné, la nécessité d'étendre une classe parent est certainement un inconvénient.
J'ai envisagé de faire du code des options de thème de Twenty Eleven une classe, mais je n'y suis jamais allé. Ce type de fonctionnalité séparée, semblable à un plugin, semble être un bon candidat pour l'encapsulation.
la source