Mirmo Dynamics - Tag - bonnes pratiques

Ergonomie d'un blog

Geoffrey — Tue, 06 Feb 2007 10:27:00 +0100

Petite étude rapide sur l'ergonomie des blogs, chez Biologeek. Le panel représentatif est peut-être un peu faible, mais l'analyse compense :-)

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 :-)

Discussion sur l'optimisation en PHP chez NiKo

Geoffrey — Thu, 23 Nov 2006 13:40:00 +0100

Une petite discussion sur l'optimisation en PHP à lieu en ce moment chez NiKo ! Ce n'est pas souvent que je link directement comme ça, donc dites vous que quand je le fais, c'est que ça en vaut la peine ;-)

Incubated

Geoffrey — Wed, 01 Nov 2006 16:10:00 +0100

Les liens interressants (ou pas) de la semaine:

J'ai pas mal entendu parler des microformats ces derniers temps, sans vraiment prendre le temps de me pencher dessus. microformats.org présente l'occasion de se plonger dedans et de comprendre que finalement, les microformats peuvent être un facteur de développement non négligeable pour un site ou une application web. GeoRSS de son côté propose une implémentation simple et puissante (c'est eux qui le disent) du Geotagging. A voir si on ne peut pas coupler tout ça avec quelques pirouettes sur Google Maps...

Pendant ce temps, chez Canonical, on établit déjà les specifications fonctionnelles de Feisty Fawn, et c'est assez prometteur :-)

Enfin, dans le petit monde du PHP et du webdev en général, il n'est jamais trop tard pour souligner l'existence de protocoles d'authentification centralisée libres comme OpenID, qui de plus à lancé un concours d'implémentation sous forme de bounties ! On notera également les débuts de l'extension d' input filtering pour PHP, qui promet de simplifier grandement la validation de données externes dans les applis PHP. Enfin, les slides de la conférences PHP Best Practices qui a eu lieu à la ZendCon, c'est vraiment rempli de bons conseils.

Bonnes pratiques PHP

Geoffrey — Sun, 29 Oct 2006 16:22:00 +0100

Vite fait, un petit jeu pour vous, amis PHPiens.

Dans le snippet de code qui suit se cachent 6 bonnes pratiques (7 selon le degré de subjectivité que l'on inclue dans une bonne pratique), saurez vous les retrouver ?

<?php

$code_is_ugly = true;
if (9069 === $code_author) {
	$code_is_ugly = false;
}

?>