Utiliser la POO dans les thèmes

Je vois beaucoup de plugins qui utilisent le codage orienté objet quand ce n'est pas vraiment nécessaire.

Mais ce qui est encore pire, c’est que les développeurs de thèmes commencent à faire la même chose. Les thèmes commerciaux et les thèmes populaires gratuits tels que Suffusion, même mon thème préféré - Hybride, englobent toutes leurs fonctions dans une classe, l'instancient une fois dans functions.php et l'exécutent de manière procédurale :)

Wtf? Quel est le point de faire cela? Évidemment, vous n'utiliserez pas deux instances ou plus du même thème, en même temps.

Supposons que les plugins le font pour l'espace de noms (ce qui est ridicule), mais quel est le prétexte du thème? Est-ce que je manque quelque chose?

Quel est l'avantage de coder un thème comme celui-ci?

Je peux comprendre votre confusion à partir de l'exemple que vous avez fourni. C'est vraiment une mauvaise façon d'utiliser une classe ... et ce n'est pas parce qu'une classe est utilisée que le système fonctionne.

Dans le cas d'Hybrid, ils utilisent simplement une classe pour nommer leurs fonctions dans l'espace de noms. Considérant que Hybrid est un framework de thèmes , ceci est fait pour que les thèmes enfants puissent réutiliser des noms de fonctions sans que le développeur ait à se soucier de la collision de noms. Dans de nombreux cas, un cadre de thème (thème parent) est si complexe que de nombreux développeurs de thèmes enfants ne comprendront jamais exactement ce qui se passe sous le capot.

Si Hybrid n'utilisait pas de structure de classe, les développeurs de thèmes enfants auraient besoin de connaître tous les appels de fonctions existants pour éviter de réutiliser des noms. Et oui, vous pouvez simplement préfixer toutes vos fonctions avec un slug unique, mais cela rend le code difficile à lire, difficile à maintenir et, par nature, non réutilisable si vous développez d'autres systèmes qui souhaitent utiliser les mêmes fonctionnalités.

Pour répondre à vos questions

Wtf? Quel est le point de faire cela? Évidemment, vous n'utiliserez pas deux instances ou plus du même thème, en même temps.

Non, vous n'utiliserez pas deux ou plusieurs instances du même thème. Mais comme je l’ai dit, considérez la structure de classe dans ce cas comme un espacement des noms des fonctions et non la création d’une instance d’objet traditionnelle. Tout regrouper dans une classe et l'instancier à appeler méthodes ( myClass->method();) ou directement à méthodes ( myClass::method();) est une manière très simple de mettre en forme des éléments d'espace de noms de manière lisible et réutilisable.

Bien sûr, vous pouvez toujours utiliser quelque chose comme à la myClass_method();place, mais si vous souhaitez réutiliser l'un de ces codes dans un autre thème, dans un plug-in ou dans un autre cadre, vous devez revenir en arrière et modifier tous vos préfixes. Garder tout dans une classe est plus propre et vous permet de réaménager et de redéployer beaucoup plus rapidement.

Supposons que les plugins le font pour l'espace de noms (ce qui est ridicule), mais quel est le prétexte du thème? Est-ce que je manque quelque chose?

Dans la majorité des situations, je suis d'accord avec vous. Cependant, cette majorité diminue rapidement. J'héberge plusieurs sites sur une installation MultiSite qui utilisent des variantes du même thème. Plutôt que de recréer le même thème, encore et encore, avec des différences mineures, j'ai une seule "classe" pour le thème parent et tous les thèmes enfants étendent cette classe. Cela me permet de définir des fonctionnalités personnalisées pour chaque site tout en maintenant un sentiment général d'uniformité sur l'ensemble du réseau.

D'une part, les développeurs de thèmes peuvent choisir une approche basée sur les classes pour leurs fonctionnalités d'espaces de noms (ce qui n'est pas ridicule si vous travaillez dans un environnement dans lequel vous réutilisez des morceaux du même code, encore et encore). D'autre part, les développeurs de thèmes peuvent choisir une approche basée sur les classes pour une extensibilité facile par thèmes enfants.

Quel est l'avantage de coder un thème comme celui-ci?

Si vous utilisez uniquement Hybrid sur votre site, il y a peu de choses à savoir pour vous, en tant qu'utilisateur final. Si vous construisez un thème enfant pour Hybrid, l’espacement des noms et l’extensibilité présentent des avantages. Si vous travaillez pour ThemeHybrid , l’avantage réside dans la réutilisation rapide et efficace du code dans vos autres projets (Prototype, Leviathan, etc.).

Et si vous êtes un développeur de thème qui aime une fonctionnalité spécifique d'Hybrid mais pas le thème entier, l'avantage réside dans la réutilisation rapide et efficace du code dans votre projet non-Hybrid (en supposant qu'il s'agisse également de la GPL).

La vitesse

Mon thème de base actuel compte 13 classes. Lorsque je construis un nouveau thème, je les utilise tels quels ou je les développe. Ce système rend le processus de construction d’un nouveau thème très, très rapide.

Portées serrées

J'ai rarement besoin de variables globales, car tout ce que mon code doit savoir est caché dans les membres de la classe. Je peux donc partager une variable entre deux filtres ou actions très différentes sans risque de collision avec des plugins mal écrits.

Entretien

Chaque classe est un fichier. Si j'ai besoin de mettre à jour le thème d'un client, il suffit de mettre à jour certains fichiers. Tout ce qui se passe à l'intérieur des classes est à moi tant que je propose la même API.

Un exemple: au-dessus de l' comment_form();appel, j'utilise une action simple:

do_action( 'load_comment_class' );
comment_form();

La classe de commentaires qui sera chargée décide de mon contrôleur. Ce qui se passe exactement à l'intérieur de la classe de commentaires décide de la classe individuelle.

Essayez ceci avec une approche purement procédurale et vous devenez fou. :)

Lisibilité

Il est tellement plus facile de relire et de comprendre votre propre code quelques mois plus tard si vous avez tout séparé par sa tâche.

Quelques exemples de hiérarchies de classes utiles

• Meta_Box-> prolongé par Shortdesc_Meta_Boxet Simple_Checkbox_Meta_Box-> prolongé parSidebar_Switch
• User_Profile_Addon-> prolongé par User_Profile_Checkbox(voir question 3255 )
• Comment_Form -> prolongé par {$theme_name}_Comment_Form

Un autre point à considérer: la vitesse.

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

Après un bref aperçu / impression, j'ai trouvé ~ 1.700 fonctions internes et ~ 1.400 fonctions utilisateur = ~ 3.100 / 3.200 fonctions VS. ~ 250 classes. Je suppose que cela en dit long sur la quantité de recherche nécessaire. Si vous appelez !function_exists('')environ 50 à 100 fonctions de votre thème, définissez une minuterie et commencez à faire des calculs. Même si ce n'est pas la POO, c'est un bon moyen de créer du code

1) réutilisable
2) maintenable
3) échangeable
4) peu plus vite

Lorsque vous jetez un coup d'œil aux différentes classes flottant sur le Web qui vous aident à créer rapidement des méta-boîtes, des widgets, etc., il est bon d'utiliser un contrôleur comme celui mentionné par @toscho, car vous pouvez simplement brancher des classes et les remplacer. certaines lignes dans le contrôleur qui gère vos classes.

Certains prétendent que l'encapsulation est le seul (ou du moins le principal avantage) qu'offre la POO, et que l'héritage et l'état se situent entre l'ennui et le mal:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

L'auteur parle davantage de l'utilisation de classes / d'objets en tant que structures que de conteneurs pour des fonctions statiques, mais il est intéressant de lire la question sous un angle complètement différent, à partir de quelqu'un qui se trouve carrément à l'extérieur du camp de la POO.

Je pourrais écrire mon prochain plugin WordPress dans Haskell.

Oh bien la discussion! Je dois également admettre que j’utilise beaucoup plus souvent les classes pour l’encapsulation. L'idée étant ici que dans mes plugins, je peux envelopper mes fonctions dans une classe et utiliser dans cette classe des noms de méthodes très simples et significatifs qui sont génériques, même parmi les autres plugins que j'écris. Dans ce cas, les classes remplacent les espaces de noms, ce que je suis obligé d'éviter pour les environnements 5.2.x.

Bien que rares soient les cas où la programmation orientée objet est utile pour la modularité, le simple fait de wrapper vos fonctions crée également le bonus supplémentaire de l'extensibilité multi-plug-in. Par exemple, j'ai récemment étendu une solution de facturation basée sur les classes, ce qui m'a permis d'étendre la classe principale, d'ajouter du code supplémentaire à diverses fonctions (w / parent :: call) ou même de remplacer des fonctions, le tout sans internaliser le plugin étendu.

Pour résumer, le retour à la classe n'est généralement qu'un substitut des espaces de noms.

Quel est l'intérêt de se plaindre d'un code que vous n'avez pas écrit?

Si vous n'aimez pas le code, écrivez le vôtre!

Simple. Problème résolu.

Les programmeurs aiment faire les choses à leur façon. Donc, ne présumez pas que vous pouvez leur dire comment écrire du code, quel type de whisky boire, quelle marque de cigarette pour fumer ou quelle religion suivre. Ils vont juste déboguer une telle diatribe et continuer à faire ce qu'ils veulent. ;-)

Le code n'est pas de la poésie. Code est une variante de la chanson de Sinatra "My Way" ...