Un soir où je soupais avec ma chère amie Marie-Eve de Meb Web. Nous avons discuté du projet Noël en Lumière qu’Absolunet a fait pour la Tablée des Chefs, un organisme qui vient en aide aux familles dans le besoin.

Je lui dis comme ça sans trop penser…

L’application en soi est très simple à faire… Je suis sûre qu’en une soirée je pourrais faire une version basique utilisable qui ressemble à ce qu’Absolunet a fait.

Je venais de me lancer un petit défi personnel.

Arrivée à la maison ce soir-là, je décidais de faire un mini Lite Brite en HTML5 / Javascript pour voir si j’étais en mesure d’accomplir ce que j’avais dit.

2-3 heures plus tard, j’envoyais un démo à Marie. Bien sûr, c’était plus une preuve de concept, mais il était possible de dessiner avec différentes couleurs sur une surface.

Le lendemain, j’ajoutais la possibilité de sauvegarder plus celle de se connecter avec son compte Facebook dans le but d’associer les dessins faits par l’utilisateur à un espace différent de sauvegarde.

Voici ce que donne la version actuel de l’application HTML5 Lite Brite.

Éventuellement j’aimerais ajouter la possibilité de partager les dessins faits par l’utilisateur sur Facebook. Pour faire cette fonctionnalité, je vais probablement utiliser la librairie GD de PHP pour produire une image GIF ou PNG similaire au dessin fait par l’utilisateur.

Par exemple lorsque vous lisez $object = new User(); vous devez vous créer une association mentale (objet signifie User) et la retenir pour être en mesure de comprendre la suite du code.

Si vous avez eu a la place $user = new User();, vous n’avez pas à vous référer à une autre ligne a un autre endroit dans le fichier ou retourner dans votre mémoire pour vous souvenir de l’association mentale. La variable est explicite et dit exactement ce qu’il y a l’intérieur. Résultat la compréhension du code s’en retrouve amélioré et facilité.

Une instance de la class User est déjà un concept abstrait puisqu’il n’est pas possible de savoir si c’est le User Roger ou Alphone.

Si vous avez une seule association, vous n’aurez probablement pas de problème à lire et comprendre. Imaginez, si vous devez faire référence à plusieurs associations, vous risquez d’avoir beaucoup de difficulté à lire et comprendre le code.

Les associations mentales avec les méthodes et fonctions

Lorsque vous définissez une fonction ou méthode qui comporte un nombre d’arguments très élevé plus de 2 ou 3, il devient difficile de se souvenir de la signification de ceux-ci sans avoir à se référer à sa définition lors de son utilisation.

CreateUser.php

1
2
3
4
5

$user = $userFactory->create(
   'Yanik', 'Lupien', 'Programmeur PHP', 
   35, '2010-10-12', '08:33', false, 3
);
$userRepo->persist($user);

Regardez, cet appel de méthode, et essayer de deviner la signification du 7e ou 8e argument.

Êtes-vous en mesure de savoir ?

Probablement pas.

Voici quelque chemin difficile possible pour y arriver.

• lire la définition de la méthode en allant consulter le fichier où se trouve la définition de la classe.
• Si vous avez de la chance que le programmeur ait correctement documenté la méthode pour que l’IDE soit en mesure de vous donner une aide contextuelle. Par exemple avec Eclipse vous pouvez avoir un accès rapide à la définition en gardant CRTL enfoncé et par un clique sur le nom de la méthode « create ».

Maintenant que vous avez trouvé le bon fichier et la bonne méthode. Vous avez maintenant la définition devant vous.

UserFactory.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

class UserFactory {
...
/**
 * Create a new user base on this exhaustive list of arguments.
 * 
 * @param string $firstName 
 * @param string $lastName
 * @param string $description 
 * @param string $age 
 * @param string $createdDate 
 * @param string $createdTime 
 * @param boolean $active User account active or not
 * @param integer $countryId Country id where the user live
 * @param integer $stateId (Optional) State id where the user live
 * @param array $options (Optional) Some options. 
 * @return User
 */
function create(
    $firstName, $lastName, $description, $age, 
    $createdDate, $createdTime, 
    $active, $countryId, $stateId = null, $options = array()
) { 
    $user = new User();
    $user->setFirstName($firstName);
    $user->setLastName($lastName);
    $user->setDescription($description);
    $user->setAge($age);
    $user->setCreatedDate($createdDate);
    $user->setCreatedTime($createdTime);
    $user->setActive($active);
    $user->setCountryId($countryId);
    $user->setStateId($stateId);
    $user->setOptions($options);
    return $user;
};
...
}

Vous regardez la définition. Pour vous simplifier la vie, vous essayez de lire à partir du dernier argument. Non ça ne fonctionne pas très bien, car ceux si sont optionnel donc vous mettez donc à compter les arguments à partir du début. Finalement, êtes en mesure de savoir que l’argument #5 est en fait le statues actif ou non et que le 6e est le ID du pays.

Les problématiques

• A la lecture du code qui utilise cette méthode il est très difficile de savoir au premier coup d’oeil quel sont les différents arguments de la function.
• Il y a aussi une duplication de la documentation de chaque propriété de la classe User. Toutes les propriétés se retrouvent redéfinies et documentées une 2e fois dans la méthode create. Nécessite une double maintenance.
• Et finalement vous avez besoin de vous souvenir par association mentale que l’argument 3 est la description, le 4 est l’age, le 5e est date, le 6e est heure et le 7e est le statues actif ou non.

Solutions

Réutilisez votre code, ici c’est la définition de la classe User qui peut être réutilisable. Plutôt que d’avoir une liste exhaustive d’arguments, utilisez l’objet lui-même.

CreateUser.php

1
2
3
4
5
6
7
8
9
10
11

$user = $userFactory->create();
$user->setId($this->getNewId());
$user->setFirstName('Yanik');
$user->setLastName('Lupien');
$user->setDescription('Programmeur PHP');
$user->setAge(99);
$user->setCreationDate('2010-10-12');
$user->setCreationTime('08:33');
$user->setActive(false);
$user->setCountryId(3);
$userRepo->persist($user);

Remarquez dans l’exemple précédent, pour comprendre chaque argument, vous n’avez plus à aller consulter la classe UserRepository. Vous n’avez plus non plus à compter ou vous souvenir de l’ordre. L’association est explicite. Le code se retrouve éclairci et beaucoup facile à comprendre.

UserFactory.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class UserFactory {
...
/**
 * Create a new user.
 * 
 * @return User
 */
function create() { 
    $user = new User();
    $user->setId($this->getNewId());
    return $user;
};
...
}

De plus, la classe UserFactory ne se retrouve plus avec un double de la définition de User.
Vous réduisez le couplage entre les 2 classes UserRepository et le User ce qui rend la maintenance beaucoup plus facile.

Il reste une dernière amélioration, et elle au niveau du setCountry. Je pourrais aussi parler au sujet setOptions qui utilise un array mais je crois que je vais faire un article complet sur le sujet.

CreateUser.php

8
9
10

...
$user->setCountryId(3);
...

Pouvez-vous me dire quelle est la signification de 3 ?

Probablement pas.

Ce qui m’apporte au sujet suivant.

Association mentale numérique

CreateUser.php

8
9
10

...
$user->setCountryId(3);
...

Le programmeur qui a bâti ce script sait probablement la signification de ce nombre. Par contre à nos yeux celui-ci ne signifie pas grand-chose. C’est peu’être… Canada, É.-U., France, Chine…

Une fois de plus nous devons chercher la source et consulter la signification de ce nombre.

Puisque le nombre de pays n’est pas si élevé et que celui-ci est généralement fixe, il nous est donc possible de définir des constantes pour rendre le code un peu plus explicite.

Country.php

1
2
3
4
5
6
7

class Country {
    const USA = 1;
    const CANADA = 2;
    const CHINA = 3;
    const JAPAN = 3;
    ...
}

Ce qui donne une lecture beaucoup plus explicite que la précédente.

8
9
10

...
$user->setCountryId(Country::CHINA);
...

Une fois de plus nous avons amélioré l’expérience de lecture pour nos collègues programmeurs.

Name space & Association mentale

Avec l’arrivé des names space dans PHP 5, plusieurs se sont lance dans leur utilisation. Encore une fois si nous le lecteur somme obliger de faire des associations mental pour comprendre le code, il est très probable que leur utilisation soit erronée.

Voici un exemple où un programmeur avait à la base une bonne intention, celle d’uniformité la structure de chaque entité de l’entreprise. Puisque chaque entité User, Site, Customer, … avait plusieurs classes telles que la classe Entite, l’interface Repository, la classe d’Exception, la classe Collection, … celui-ci s’est dit je vais créer un espace de nom propre a chaque entité.

Voici la structure des namespace et ses fichiers

namespace MyCompany\User;
Libs\MyCompany\User\Collection.php
Libs\MyCompany\User\Entity.php
Libs\MyCompany\User\Exception.php
Libs\MyCompany\User\Repository.php
...
namespace MyCompany\Site;
Libs\MyCompany\Site\Collection.php
Libs\MyCompany\Site\Entity.php
Libs\MyCompany\Site\Exception.php
Libs\MyCompany\Site\Repository.php
...
namespace MyCompany\Customer;
Libs\MyCompany\Customer\Collection.php
Libs\MyCompany\Customer\Entity.php
Libs\MyCompany\Customer\Exception.php
Libs\MyCompany\Customer\Repository.php

À première vue l’idée semble bonne. Tous les fichiers sont uniformisés. C’est bien organise et en ordre. Il n’y a pas de redondance dans le les noms. C’est propre et la structure de fichier est claire.

Maintenant voici la définition de la classe MyCompany\User\Entity et MyCompany\User\Repository

Lib\MyCompany\User\Entity.php

8
9
10
11

namespace MyCompany\User;
class Entity {
 
}

Lib\MyCompany\User\Repository.php

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

namespace MyCompany\User;
interface Repository {
    /**
     * Find entity by unique id
     * @return Entity
     */
    function findById($id);
 
    /**
     * Find a entity by name
     * @return Collection
     */
    function findById($name);
 
    /**
     * Save an entity to repository
     * @param Entity $entity Entity to save in repository
     * @return void
     */
    function save(Entity $entity);
}

À première vue les classes semblent bien organise.

Voici les problématiques

• Pour comprendre le fichier il est toujours nécessaire de faire référence a une association mentale et où de se remettre en contexte.
• A la lecture du code de ces classes, il est facile de penser que ce sont des définitions abstraites puisque les noms Entite, Repository, … font référence à des concepts très abstraits que la spécialisation qui est décrit par ces fichiers. Il faut se référer à l’espace de nom pour comprendre la signification du context de celui çi.
• les méthodes sont aussi documentées relativement à l’espace de nom. Par exemple, la méthode findByName plutôt que de retourner un UserCollection retourne une Collection encore une fois la notion de Collection fait référence à une notion très abstraite. Alors que dans les fait cette méthode retourne une UserCollection, une instance très spécialisée.
• comme les noms de classes et interfaces, les noms de fichiers porte le même nom que ceux-ci et font donc aussi référence à un concept abstrait non spécialisé. Si vous ouvrez 4 fichiers Entity.php dans un IDE comme Eclipse, il devient très difficile de s’orienter et de savoir dans quelle spécialisation nous sommes.

Solutions

Dans le cas actuel, renommer les fichiers, les classe, les variables et les commentaires à leur spécialisation aiderait énormément la compréhension. Dans le cas actuel, il est vrai qu’il y aurait une redondance du nom dans la structure. L’avantage gagné au niveau de la lecture et compréhension du code compense largement cette petite redondance. Il y a toujours possibilité de changer la structure

8
9
10
11
12

namespace MyCompany\Customer;
Libs\MyCompany\Customer\CustomerCollection.php
Libs\MyCompany\Customer\CustomerEntity.php
Libs\MyCompany\Customer\CustomerException.php
Libs\MyCompany\Customer\CustomerRepository.php

Lib\MyCompany\User\UserRepository.php

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

namespace MyCompany\User;
interface UserRepository {
    /**
     * Find UserEntity by unique id
     * @return UserEntity
     */
    function findById($id);
 
    /**
     * Find a entity by name
     * @return UserCollection
     */
    function findById($name);
 
    /**
     * Save an UserEntity to current repository
     * @param UserEntity $user User to save in repository
     * @return void
     */
    function save(UserEntity $user);
}

Conclusion

Un collègue programmeur m’a envoyé une « Quote » intéressante, la voici :
« There is a cost associated to mental mapping… if you’re adding required mental mapping in your code, you are stealing from you employer ».

En tant que développeur professionnel nous nous devons d’écrire un code clair où il est facile de se retrouver et où il est facile de comprendre l’objectif de celui-ci. Un code clair est explicite, prévisible et surtout facile à lire et comprendre sans besoin d’utiliser d’associations mentales.

Références

books.google.ca / Clean Code: A Handbook of Agile Software Craftsmanship

Trop souvent les programmeurs PHP ont utilises les constantes pour différent usage tel que configuration, langage, variable globale. Une constante devrait être une valeur qui ne change pas tout au long de l’existence de l’application et non tout au long de l’exécution du script.

Par exemple si vous avez une classe RGB vous pourriez avoir la constante RGB::RED = #FF0000 cette valeur est une valeur constante elle ne changera jamais. Ce n’est pas d’avoir une valeur qui ne change pas tout au long de l’application, mais bien une valeur qui est constante qui ne change pas.

L’utilité principale des constantes est de clarifier votre code, de donner un nom plus humain et facile a lire. Par exemple, vous avez surmènent déjà eu des fonctions / method telle que

1

$logger->log('blabla', 3, 1 | 4);

Mettez-vous a la place dans les souliers du programmeur neuf qui arrive et regarde cette ligne. Au premier coup d’oeil, il est facile de voir que l’ont veut logger « blabla » mais pour le reste… Aucune idée de ce que c’est.

Voici des exemples d’une meilleur utilisation des constantes.

1
2
3
4
5

$logger->log(
   'blabla',
   ILog::LEVEL_WARNING,
   ILog::OPTION_DELAYED | ILog::OPTION_MERGE
);

De cette façon, nous ne somme pas obliger d’aller voir la définition de la méthode pour la comprendre que le 2e paramètre est le niveau sévérité du message et que le 3e sont les options.

Voici l’exemple du RGB.

1
2
3
4
5
6
7
8
9
10
11
12

class RGB {
  const RED   = '#ff0000';
  const BLUE  = '#0000ff';
  const GREEN = '#00ff00';
  ...
}
 
// Sans constante
$color = new RGB('#ff0000');
 
// Avec constante
$color = new RGB(RGB::RED);

2.Apprenez des autres langages et appliquez leurs principes

En C++ il est possible de définir certaines méthodes d’une classe comment étant constante. En Java un principe similaire est la définition d’interface mutable et non mutable. Le but ici est simple, c’est d’exposer à l’utilisateur de la classe que l’appel à ces méthodes ne changera pas l’état de l’instance.

Si vous appelez getName() sur l’instance utilisateur il ne devrait y avoir aucune variables membre de l’instance utilisateur qui devrait changer. Cette méthode est donc constante / non mutable. Tous les getter de façon générale devraient être constant / none mutable et ne devrait pas altérer l’état de l’instance.

En PHP il n’est pas possible de définir une méthode constante, mais il est toujours possible d’applique le principe que lorsque vous définissez un getter vous n’altérez pas l’état de votre instance.

Voici un exemple d’interface non mutable et mutable.

1
2
3
4
5
6
7
8
9

interface IUser {
  function getFirstName();
  function getLastName();
}
 
interface IUserMutable extends IUser {
  function setFirstName($s);
  function setLastName($s);
}

3.Maîtrisez l’utilisation des interfaces

En C++ et Java, les interfaces ne sont pas simplement une façon de s’assurer l’existence de méthodes. C’est avant tout un contrat qui définit quelles méthodes peuvent être appelées.

Exemple d’une definition d’interface en C++

1
2
3
4
5
6

class IUser {
public:
  virtual ~IUser() {}
  virtual const string getFirstName() const = 0;
  virtual const string getLastName() const = 0;
};

Dans l’exemple ci-haut c’est une définition d’interface IUser avec une méthode getFirstName constante qui retourne une chaîne constante. Au final, l’appel de cette méthode sur une instance ne devrait pas changer l’état de celle çi. De plus, il ne devrait pas non plus être possible de changer la chaîne retourne. Il serait nécessaire de faire une copie pour être en mesure de la changer. Cette démarche assurer l’intégrité de l’espace mémoire utilisé par l’instance User.

Un des points importants est que ces langages empêchent l’appel d’autres méthodes qui ne sont pas définies dans l’interface.

Si dans la définition d’une méthode, vous spécifiez que vous vous attendez a recevoir une interface IUser rien ne vous empêche, d’appeler setFirstName qui fait partie de l’interface (IUserMutable). Or le jour ou vous allez passer à cette méthode une instance qui supporte seulement l’interface IUser votre allez vous apercevoir que votre méthode en fait plus qu’elle ne semble le laisser voir.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

interface IUser {
  function getFirstName();
  function  getLastName();
}
 
interface IUserMutable extends IUser {
  function setFirstName($s);
  function setLastName($s);
}
 
class ConstantUser implements IUser {
  function getFirstName() { return $this->fName; }
  function getLastName() { return $this->lName; }
}
 
class DynamicUser implements IUserMutable {
  function getFirstName() { return $this->fName; }
  function getLastName() { return $this->lName; }
}
 
// Ici la fonction expose a l'utilisateur qu'elle a besoin d'un IUser
// alors qu'en réalité elle devrait exposer qu'elle a besoin d'un IUserMutable
function doMore(IUser $user) {
  // cette méthode fait partie de l'interface IUser
  $user->getFirstName(); 
  // Cette methode ne fait pas partie de l'interface IUser
  $user->setFirstName('Yanik'); 
}
 
$dUser = new DynamicUser();
doMore($dUser); // OK
 
$cUser = new ConstantUser();
doMore($cUser); // CRASH

En C++ ou Java il serait absolument nécessaire de caster le pointer à l’interface voulue.
Exemple de casting C++

1
2
3
4
5
6

void functionName(IUser * user) {
  IUserMutable * userMutable = dynamic_cast<IUserMutable *>(user);
  if (userMutable != null) {
    userMutable->setFirstName('Yanik');
  }
}

Exemple de casting Java

1
2
3
4
5
6

void public function functionName(IUser user) {
  IUserMutable userMutable = (IUserMutable) user;
  if (userMutable != null) {
    userMutable.setFirstName('Yanik');
  }
}

Exemple de faux casting PHP

1
2
3
4
5
6
7
8
9
10

 
function functionName(IUser $user) {
  $userMutable = null;
  // Faux casting ;-) 
  // Le but est simplement de rendre le code plus clair sur l'intention
  if ($user instanceof IUserMutable) {
    $userMutable = $user; 
    $userMutable->setFirstName('Yanik');
  }
}

4.Utilisez la puissance de json_encode et limitez les points de contact

Dans le développement d’application web, il est souvent nécessaire d’utiliser JavaScript. Trop souvent j’ai vu du code PHP générer par condition et concaténation plusieurs segments de code javascript. Que ce soit la construction de tableau, d’objet ou de fonction. Cette façon de produire du javascript rend la lecture et la compréhension du code javascript et PHP presque qu’impossible et le résultat ressemble souvent a un code offuscater.

Limitez les points de contact entre PHP et JavaScript. Dites-vous qu’a chaque fois que PHP produit un bout de JavaScript par un echo ou une concaténation c’est un point de contact.

Exemple A

1
2
3
4
5
6
7
8

<script>
<?php
$js = 'var user = new User({'; // Point de contact
if ($firstName) { $js .= "'{$firstName}',"; } else { $js .= 'null,'; } // Point de contact
if ($lastName) { $js .= "'{$lastName}',"; } else { $js .= 'null,'; } // Point de contact
echo $js + "});"; // Point de contact
?>
</script>

Exemple B

1
2
3
4
5
6
7

<?php $prop = array('firstName' => 'Yanik', 'lastName' => 'Lupien'); ?>
 
<script>
// Section Javascript
var prop = <?php echo jsonencode($prop); ?>; // Point de contact
var user = new User(prop);
</script>

Les deux codes si hauts donnent presque un résultat identique. Dans l’exemple A pour construire l’instance du user l’utilisation de la concaténation de segment javascript et variable PHP. Un des inconvénients de cette pratique est qu’il n’y a pas de prise en charge des valeurs avec quote. Soit le Javasctipt va se briser soit il est possible d’injecter du javascript.

Dans l’exemple B chaque langage est clairement séparer le seul point de contact entre les deux est ou il y a l’assignation de la variable prop.

5.Éradiquez la maladie du singleton / multiton

Qui n’a pas déjà fais quelque chose qui ressemble a User::getInstance(4); ce patron de conception s’appelle un Multiton c’est l’équivalent d’un singleton, mais avec un cle par instance. La classe User fait probablement partie de votre business logique de votre application. Ici se posent deux problématiques.

La première problématique, où se trouve la source de données?

La deuxième comment réutiliser votre classe avec une autre source de donnes ?

Dans la même logique je serais porter a faire une nouvelle méthode User::getInstanceFromFile(‘user-6.txt’) pour récupérer une instance à partir d’un fichier…

Le singleton en soit n’est pas une mauvaise pratique c’est l’utilisation par appel statique qui n’est pas très bonne. Tout dépend du contexte bien sûr.

Conclusion : très rapidement la classe va se retrouver polluer d’une quantité incroyable de méthodes statique qui récupère des User de différentes façons et de plusieurs endroits différents avec plusieurs conditions différentes. Sans parler de dépendances externes que vous ajoutez à vos classes business.

6.Fuyez les variables globales orientées objet

Pour ceux qui ont déjà travaillé avec Zend_Framework, vous avez sûrement déjà vu la classe Zend_Registry. Cette classe est une belle variable globale orientée objet. Le programmeur qui utilise cette classe se sent en paix avec lui même, car il a la certitude de faire du beau code. C’est vrai qu’il n’y a pas le mot GLOBAL. Mais dans la réalité c’est une classe qui wrap une variable globale. Zend_Registry::getInstance() retourne une instance unique du registry peut importe l’emplacement ou nous somme dans l’application. Et par la suite il est possible de récupérer un élément par un nom.

Dite vous qu’a chaque fois que vous faite un appel statique a une classe extérieure sans l’avoir passé a la votre classe vous venez d’ajouter une dépendance externe qui risque de vous causer beaucoup de problèmes lorsque vous allez vouloir utiliser cette même classe dans un autre contexte.

Pour pallier à ceci, utiliser l’injection des dépendances. Si une votre class a besoin d’un logger pour son fonctionnement injectez lui.

7. Définissez toujours de façon explicite l’origine des variables

Avez-vous déjà défini une variable dans un fichier PHP et l’utiliser dans un autre ? Regardez l’exemple si dessous. Si nous somme dans le contexte du fichier index.php il n’est pas très clair de savoir de ou provient la variable $menu pourtant elle est la. Avec cette façon de développer, il y a aussi un gros risque de collision et d’erreurs. Maintenant que se passe t’il si un développeur ajoute au fichier initialize.php une variable $menu ?

config.php

1
2

$config = "myconfig.ini";
$menus = array('Contact', 'About', 'Products')

index.php

1
2
3

require_once('config.php');
require_once('initialize.php');
foreach($menus as $menu) { .. }

Arrêtez vous un instant et placez-vous dans les souliers d’un autre programmeur qui arrive dans le projet. Regardez le fichier index.php et posez-vous la question d’où provient $menus ? Etes vous en mesure de dire si c’est config.php ou initialize.php ?

Pour que le code soit lisible et facile à comprendre, il est toujours important de voir les entrées et sorties. Dans l’exemple il n’est pas possible de voir l’entrée / la provenance de $menu.

Pour corriger cette problématique, une façon simple serait simple d’ajouter une fonction et un return à la fin du fichier. L’utilisation d’une fonction rend toutes les variables utilisées dans le fichier config.php privé donc il n’affecter pas le scope globale. Le code se trouve aussi clarifie, puisque maintenant il est facile de suivre la provenance de la variable $menu.

config.php

1
2
3
4
5
6

function config() {
  $config = "myconfig.ini";
  $menus = array('Contact', 'About', 'Products')
  return array('menus' => $menus);
}
return config();

index.php

1
2
3

$configs = require_once('config.php');
$inits = require_once('initialize.php');
foreach($config['menus'] as $menu) { .. }

Merci pour votre lecture.

Références

• http://en.wikipedia.org/wiki/Dependency_injection
• http://fr.wikipedia.org/wiki/Singleton_%28patron_de_conception%29
• http://en.wikipedia.org/wiki/Multiton_pattern
• http://en.wikipedia.org/wiki/Constant_%28programming%29

Technologies : PHP, Javascript/jQuery, XHTML/CSS, Facebook API

Adresse : http://apps.mystart.com/partners/default/widget_details.php?wid=1324

Technologies utilisées : jQuery, XHTML/CSS

Adresse : http://www2.mystart.com/

Technologies utilisées : PHP/MySQL, jQuery, XHTML/CSS et GD, PHPExcel, WordPress

Adresse :  http://www.autobusgalland.com/

Technologies utilisé : PHP/MySQL, jQuery, AJAX, XHTML/CSS, JSON, VMN Toolbar

Adresse : http://apps.mystart.com/partners/default/widget_details.php?wid=1300

Technologies utilisées : PHP/MySQL, XHTML/CSS, jQuery

Adresse : http://www.centrebodyshop.com/fr/services

Addresse : http://fraisebec.tapage-web.com/inscription.php