En utilisant OOP en 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 thème framework , cela 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, imaginez dans ce cas la structure de la classe comme namespacing les fonctions, sans créer une instance d’objet traditionnelle. Tout regrouper dans une classe et l'instancier pour appeler des méthodes (myClass->method();) ou appeler directement des méthodes (myClass::method();) est un moyen très simple de restituer les éléments d'un espace de noms de manière lisible et réutilisable.
Bien sûr, vous pouvez toujours utiliser quelque chose comme myClass_method();, mais si vous souhaitez réutiliser ce code dans un autre thème, dans un plug-in ou dans un autre framework, vous devez revenir en arrière et modifier tous vos préfixes. Garder tout dans une classe est plus propre et vous permet de redévelopper 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. I Hébergez 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 qui vous avantage 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-hybride (en supposant qu'il s'agisse également de 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'appel comment_form();, 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 exactement se passe à l'intérieur de la classe de commentaires décide de la classe individuelle.
Essayez-le avec une approche purement procédurale et vous devenez fou. :)
Lisibilité
Il est tellement plus facile de relire et 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-> étendu parShortdesc_Meta_BoxetSimple_Checkbox_Meta_Box-> étendu parSidebar_SwitchUser_Profile_Addon-> étendu parUser_Profile_Checkbox(voir Question 3255 )Comment_Form-> étendu 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 pour !function_exists('') sur environ 50 à 100 fonctions de votre thème ... définissez simplement une minuterie pour une, puis commencez à faire quelques calculs. Même si ce n'est pas OOP c'est un bon moyen de faire 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 avancent que l'encapsulation est le seul (ou du moins le principal avantage) que OOP offre, 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/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, de quelqu'un qui se trouve carrément à l'extérieur du camp OOP.
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 se substituent aux espaces de noms, ce que je suis obligé d'éviter pour les environnements 5.2.x.
Même si rares sont les cas où OOP est utile pour la modularité, le simple fait de wrapper vos fonctions crée également un bonus supplémentaire en termes d'extension du plugin. 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.