Mirmo Dynamics - Tag - oop

Extending Zend_Controller_Router_Route: the singleton problem.

Geoffrey — Mon, 05 Nov 2007 14:37:00 +0100

Today I ran into an issue while extending Zend_Controller_Router_Route. I wanted to add a little path pre/post processing in the match() and assemble() methods, so I just extended the Route class to add my tiny bits of code into the methods. Except it did not work at all. After a few debuging, it turned out that the Router uses Zend_Controller_Router_Route::getInstance() to retrieve a route object, which uses a new self(); statement to instantiate the route object. Problem is that self always refers to the current class definition we're in, if the method is called from a child class, without being overloaded, self will refer to the wrong class.

Example:

class Foo {

        public static function getInstance() {

                return new self;

        }

}



class Bar extends Foo {}



var_dump(Bar::getClass());

echoes something like:

object(Foo)#1 (0) {
}

Which is fscking wrong IMHO. A quick workaround is to overload the getInstance method, which is what I call pretty annoying as it does not follow the DRY principle.

Stripping the logic: the Transfer Object

Geoffrey — Sat, 11 Aug 2007 11:56:00 +0200

Sometimes you have to pass an object data to another object, or to another layer of your application (who said controller/view ?), while ensuring that the receiving entity will not be able to run business code encapsulated in your class. In the Zend Framework, several objects provide a toArray method, but that is not always sufficient as sometimes you'd like to keep with the $object->varname syntax.

That is where the Transfer Object arrives. While the preceding definition is not exact (that's not the real purpose of the Transfert Object in the J2EE spirit), This is the most common use that PHP Developers can make of it nowadays I think. So I came up with a very light implementation of a concept which I hope can prove useful for any folks getting by there.

Interfaces et Classes Abstraites

Geoffrey — Wed, 31 Jan 2007 09:08:00 +0100

Les concepts de classes abstraites et d'interfaces sont souvents assez flous quand on débute dans la programmation objet, et on se fourvoie assez souvent sur leur utilisation et leur but. Voila une petite explication qui j'espère sera 1) juste et 2) assez claire pour tout le monde. Si vous pensez que je me fourvoie sur ces 2 concepts de base de la POO, n'hésitez pas à me le faire savoir !

Commençons par le commencement: l'Interface. Une Interface définit une API (Application Programming Interface), dont le seul et unique but est de décrire les méthodes disponibles pour un objet donné. Une Interface ne contient pas de code fonctionnel, seulement des synopsis de méthodes et d'attributs. Par exemple, l'utilisation du mot clé "instanceof" permet de déterminer si un objet donné implémente ou non une interface donnée, et d'adapter le comportement de l'application selon la réponse. Le "type hinting" permet également ce genre de choses:

<?php

interface Bar_Interface {
      public function doSomething();
}

class Bar implements Bar_Interface {
      public function doSomething() {
            echo "something was done.";
      }
}

class Foo {
      public function doSomething(Bar_Interface $bar) {
            $bar->doSomething();
      }
}

?>

Dans cet exemple, quand Foo::doSomething() est executée, on est certain que l'objet $bar dispose de la méthode doSomething car il implémente l'Interface Bar_Interface.

Vient ensuite la classe abstraite. La classe abstraite, "abstract class" en V.O., se comporte comme un squelette d'objet. Elle est utile dans le cas où on utilise une série d'objets d'une même famille qui partagent du code commun, mais qui comportent tous leurs particularités propres. Dans ce cas de figure, on commence par implémenter le code commun dans la classe abstraite, dont hériteront les autres objets, dans lesquels le code spécifique pourra à son tour être implémenté. C'est très utile pour certains Design Pattern, comme par exemple "Adapter" ou "Proxy", qui ont tous deux pour but de permettre des stratégies différentes pour une même situation, situation qui présente le plus souvent des points similaires quelque soit la stratégie adoptée.

En règle générale, une classe abstraite implémente une interface (et un exemple d'Adapter en cadeau bonux):

<?php

interface Bar_Adapter_Interface {
      public function doSomething();
}

class Bar {
      public function __construct(Bar_Adapter_Interface $adapter) {
            $this->_adapter = $adapter;
      }

      public function doSomething() {
            return $this->_adapter->doSomething();
      }

      static public function factory($adapter) {
            $className = "Bar_Adapter_".$adapter;
            if (!class_exists($className)) {
                  throw new Exception('Adapter not available: '.$adapter);
            } else {
                  return new Bar(new $className);
            }
      }
}

abstract class Bar_Adapter_Abstract implements Bar_Adapter_Interface {
      protected function getSomething() {
            return "la méthode pour accéder a ce truc est la même pour tout le monde";
      }
}

class Bar_Adapter_Explode extends Bar_Adapter_Abstract {
      public function doSomething() {
            return explode(' ', $this->getSomething());
      }
}

class Bar_Adapter_PregSplit extends Bar_Adapter_Abstract {
      public function doSomething() {
            return preg_split('/ /', $this->getSomething());
      }
}

$bar = Bar::factory('Explode');
print_r($bar->doSomething());

?>

Ici, l'objet Bar offre la méthode doSomething, qui présentement retourne une chaine explosée, et on propose deux adapteurs pour se faire, l'un utilisant explode(), l'autre preg_split(). Bien sur, cet exemple est complètement trivial :-)