Utilisation de la POO dans les thèmes

35

Je vois beaucoup de plugins qui utilisent le codage orienté objet quand il n'y en a pas vraiment besoin.

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?

    
posée onetrickpony 22.12.2010 - 11:36

6 réponses

26

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 un espace de noms. Considérant que Hybrid est un framework de thème, cela est fait de sorte que les thèmes enfants puissent réutiliser des noms de fonctions sans que le développeur n’aie à s’inquiéter 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 les 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 intrinsèquement non réutilisable si vous développez d'autres systèmes qui souhaitent utiliser les mêmes fonctionnalités. / p>

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 instances ou plus du même thème. Mais comme je l’ai dit, considérez la structure de la classe dans ce cas comme namespacing , sans créer une instance d’objet traditionnelle. Tout regrouper dans une classe et l’instancier à appeler des méthodes ( myClass->method(); ) ou à appeler directement des méthodes ( myClass::method(); ) est un moyen très simple d’afficher des éléments d’espace de noms de manière lisible et réutilisable.

Bien sûr, vous pouvez toujours utiliser quelque chose comme myClass_method(); à la place, mais si vous souhaitez réutiliser ce code dans un autre thème, dans un plug-in ou dans un autre cadre, vous devez revenir en arrière et le 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 (ce qui n'est pas ridicule si vous travaillez dans un environnement dans lequel vous réutilisez des morceaux du même code à plusieurs reprises). Par ailleurs, 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, vous n’avez guère d’avantages à connaître les avantages 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-hybride (en supposant qu'il s'agisse également de la GPL).

    
réponse donnée EAMann 22.12.2010 - 16:58
29

Vitesse

Mon thème de base actuel compte 13 classes. Lorsque je construis un nouveau thème, j'utilise ces classes telles quelles 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.

Maintenance

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 dans les 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 se passe exactement dans 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 - > étendu de Shortdesc_Meta_Box et Simple_Checkbox_Meta_Box - > étendu de Sidebar_Switch
  • User_Profile_Addon - > étendu de User_Profile_Checkbox (voir Question 3255 )
  • Comment_Form - > étendu de {$theme_name}_Comment_Form
réponse donnée fuxia 22.12.2010 - 12:27
3

Autre point à prendre en compte: la vitesse.

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

Après un bref aperçu / une impression, j'ai trouvé ~ 1.700 fonctions internes et ~ 1.400 fonctions utilisateur = ~ 3.100 / 3.200 fonctions VS. ~ 250 classes. J'imagine que cela en dit long sur les besoins en recherche. 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 de 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 à l'intérieur et à l'extérieur. et remplacez simplement quelques lignes dans le contrôleur qui gère vos classes.

    
réponse donnée kaiser 03.03.2011 - 21:55
2

Certains avancent que l’encapsulation est le seul (ou au moins le principal avantage) offert par la POO, et que l’héritage et l’état se situent entre ennuyeux et diabolique:

enlace

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 de la POO.

Je pourrais écrire mon prochain plugin WordPress dans Haskell.

    
réponse donnée Tex 07.04.2011 - 15:23
2

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é entre plug-ins. 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.

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

    
réponse donnée Jester831 26.04.2011 - 03:37
-3

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 manière. 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. Le code est une variante de la chanson de Sinatra "My Way" ...

    
réponse donnée Mark 23.12.2010 - 05:44

Lire d'autres questions sur les étiquettes