web-dev-qa-db-fra.com

Appliquer OO modèles et principes pour le développement de plugins

Je suis en train d'écrire mon premier plugin, en utilisant PHP 5.3.5. Je viens d'un environnement C #, et je dois dire que je suis plus que satisfait du niveau de prise en charge de bonnes techniques OOPsolides en PHP. Cependant, je ne sais pas trop comment structurer un plugin en utilisant des classes. J'ai une classe de plugin qui s'occupe de l'enregistrement du hook dans son constructeur, et certaines classes de travailleurs comme une file d'attente et un mailer, mais j'ai un ou deux scripts non-classes, principalement pour les formulaires, que je ne sais pas trop comment s'intégrer parfaitement dans les classes. Quelles sont les ressources que je peux consulter pour obtenir des conseils sur cet aspect de mon plugin OO?

Le plugin est destiné au publipostage en masse, c.-à-d. À tous les abonnés, dans les délais prévus, etc. Il enregistre un type de publication personnalisé pour les modèles de courrier, avec des fonctions d’ajout et de modification, et ajoute son propre menu au bas du menu admin, actuellement avec deux pages de sous-menu: "paramètres" et "envoyer un courrier". Il ajoute également une option de "désinscription" à la page de profil de l'utilisateur, mais c'est assez ordonné et facile à inclure la classe de plugin principale.

plugin-developmentphpcustomizationdesignoop
1
ProfK

J'ai un ou deux scripts hors classe, principalement pour les formulaires, que je ne sais pas comment s'intégrer parfaitement dans les classes.

Divisez votre projet en plusieurs classes. Conservez vos classes de travail en tant qu'objets instanciables (modèles OOP typiques) et placez vos scripts non-classes dans une classe qui leur est propre, en tant que scripts statiques.

J'utilise souvent des classes PHP statiques pour nommer mon code de cette façon. Exemple:

class My_Object {
    public $variable = 1;

    public function __construct() {
        // Constructor
    }

    public function do_something() {
        // Misc. method for the object
        $this->variable++;
    }
}

static class Helper {
    public static function Run_Script() {
        // Function that does something and doesn't belong in a class
    }
}

La différence entre ces deux classes est que vous en instanciez un (My_Object) et que vous l'utilisez en tant qu'objet. L'autre est fondamentalement un encapsuleur d'espace de nom pour une fonction qui n'appartient pas à un objet mais qui n'appartient pas non plus à l'espace de nom global.

Supposons que vous ayez commencé avec une méthode Run_Script() régulière dans votre plug-in ... puis qu'un autre développeur ajoute une méthode Run_Script() à un autre plug-in. Vous avez maintenant un conflit de noms. Garder vos fonctions autonomes dans une classe statique aide à éviter cela.

Il suffit d'appeler Helper::Run_Script() pour y accéder.

Quelles ressources puis-je consulter pour obtenir des conseils sur cet aspect de mon plugin OO?

Fondamentalement, regardez ce que d'autres ont fait. Il existe de nombreux plugins de qualité qui suivent ce type de modèle. Alors jetez un coup d'œil à la façon dont d'autres ont abordé le problème et tirez les leçons de leur exemple.

GitHub est un bon endroit pour regarder le code. La plupart de mes plugins sont là-haut, vous pouvez donc parcourir les fichiers de code pour afficher la structure sans avoir besoin de les télécharger et de les installer.

Quelques bons développeurs sur GitHub que vous devriez suivre pour plus d'exemples:

2
EAMann
class Plugin{
    static public function Construct(){
        static $single_call = false; // Enable calling this just once
        if($single_call) return; // Skip double hooking
        add_filter('the_content', array(__CLASS__, 'TheContent'));
        $single_call = true; // Block future calls
    }
    /**
     * @internal
     */
    static private function ContentModifier($content){
        return $content;
    }
    // All actions/filters must be public, internal methods can stay private
    static public function TheContent($content){
        return self::ContentModifier($content);
    }
}
Plugin::Construct(); // Single Call

Créez des classes statiques pour les plugins. Les actions/filtres doivent être publics.

Et, lorsque vous utilisez PHP 5.3+, considérez les fermetures pour lesquelles vous avez besoin d'actions/filtres à usage unique et difficiles à supprimer.

add_filter('the_content', function($content){
    return $content;
});

Je viens de C++ , Bienvenue en PHP!

0
EarnestoDev