Surchargeant les méthodes statiques en PHP

J'ai une page de résumé de la classe comme ceci:

abstract class Page {
    public static function display() {
        self::displayHeader();
        self::displayContent();
        self::displayFooter();
    }

    public static function displayContent() {
        print "<p>some content</p>";
    }

    public static function displayHeader() {
        include_once(kContent . "HeaderContent.class.php");
        HeaderContent::display();
    }

    public static function displayFooter() {
        include_once(kContent . "FooterContent.class.php");
        FooterContent::display();
    }
};

Je voudrais sous-classe de ce, et remplacez uniquement les displayContent méthode, de sorte que l'en-tête et pied de page est affiché automatiquement, mais ayant encore la possibilité de remplacer la méthode d'affichage, par exemple pour .js fichiers.

Maintenant, j'ai une autre classe, comme ceci:

class FooPage extends Page {
    public static function displayContent() {
        print "<p>Foo page</p>";    
};

Maintenant, au lieu d'appeler la FooPage de displayContent méthode, il se contente d'appeler celui de la classe mère.

Pourquoi? Que puis-je faire?

MODIFIER

Je suis en cours d'exécution PHP 5.2.17

Utilisation static au lieu de self.
double possible de lors de l'utilisation de l'auto, le parent, le statique et comment?
pas un doublon, n'a pas fonctionné pour moi.
Pourquoi le display() méthode statique? Ne pas le faire, si vous disposez déjà d'un objet. Et puis l'héritage fonctionne avec $this.
Ensuite, vous n'obtenez pas d'héritage en retour. 🙂 B::foo() sera de passer à travers A:foo() à cause de la statique de la liaison et il cherchera à A::foo() comme si il a été appelé directement. Vraiment rien que vous pouvez faire à ce sujet.

OriginalL'auteur NSAddict | 2012-11-01

  1. 7

    Ilija, PHP < 5.3 n'a pas "Late Static Binding" et c'est pourquoi vous avez peut-être l'expérience de la FooPage::displayContent n'est pas appelée. Si vous utilisez PHP 5.2 ensuite, il n'y a rien à faire (sauf pour certains hacks à l'aide de debug_backtrace(), honnêtement, je ne le recommande pas pour cette situation).

    Maintenant, il appelle mon attention, c'est que vos méthodes sont toutes statique; est-il une raison pour cela? Pourquoi ne sont-ils pas des méthodes d'instance? Je m'attends à quelque chose comme:

    include_once(kContent . "HeaderContent.class.php");
include_once(kContent . "HeaderContent.class.php");

abstract class Page 
{
    protected $header;
    protected $footer;

    public function __construct()
    {
        $this->header = new HeaderContent();
        $this->footer = new FooterContent();
    }

    public function display() 
    {
        $this->displayHeader();
        $this->displayContent();
        $this->displayFooter();
    }

    public function displayContent() 
    {
        print "<p>some content</p>";
    }

    public function displayHeader() 
    {
        $this->header->display();
    }

    public function displayFooter() 
    {
        $this->footer->display();
    }
};

class FooPage extends Page 
{
    public function displayContent() 
    {
        print "<p>Foo page</p>";
    }
}

    et, plus tard, à votre avis, on peut écrire quelque chose comme:

    $page = new FooPage();
$page->display();

    Certaines choses à prendre en compte:

    • Il est généralement préférable de ne pas utiliser d'impression/l'écho lors de la génération d'un point de vue contenu. Au lieu d'essayer de créer la chaîne et de faire de l'imprimer/l'écho comme une dernière étape. Cela rend plus facile pour plus tard écrire des tests.

    Exemple:

    public function display() 
{
    return 
           $this->displayHeader() . 
           $this->displayContent() . 
           $this->displayFooter();
}

public function displayContent() 
{
    return "<p>some content</p>";
}

public function displayHeader() 
{
    return $this->header->display();
}
....
$page = new FooPage();
echo $page->display();
    • Si vous avez besoin de le faire en tant que votre demande se développe, vous pouvez passer à l'en-tête et pied de page comme la Page paramètres du constructeur. Tant qu'ils sont des objets qui comprennent l'affichage de la (des) message (c'est à dire polymorphe), les choses devraient être ok.

    HTH

    Merci beaucoup pour votre réponse! Ok, il a travaillé avec les méthodes statiques. Ce que je fais avec l'impression est la suivante: ob_start(); $this->output = ob_get_contents(); ob_get_clean(); Est-ce trop sale?
    C'est dire, donc je peux imprimer des trucs par fermer les balises php, insérer mon code html, et en ouvrant les balises php à nouveau. Donc, je reçois la coloration syntaxique.
    Eh bien, c'est plus du tout une question de goût et chaque personne est d'avis sur "élégant" de codage. Je préfère laisser le ob_start(); mécanisme pour les moments où il est le seul choix. De mon POV de retourner une chaîne de caractères est un plus élégant approche, au prix de perdre la coloration syntaxique. Comme beaucoup d'autres choses, c'est la programmation il y a toujours un compromis à faire et vous devez choisir celui qui correspond le mieux à vos besoins. Toutefois, si vous allez avec le ob_start() approche, je vous conseille de créer une sortie "grabber" objet qui encapsule dans une méthode, de sorte que vous ne répétez pas les ob_* processus N fois.

    OriginalL'auteur Andrés Fortier