Lorsqu’on commence à créer un site internet, on commence généralement avec un seul fichier, c’est très pratique. Mais rapidement, la taille du fichier devient trop grande. Comment faire pour découper mon code dans plusieurs fichiers ? Quelle organisation utiliser pour garder un projet cohérent ? Comment faire en sorte pour pouvoir maintenir facilement notre site ? Voici le genre de questions qui arrivent rapidement et auxquelles je vais répondre dans cet article !

Note : Cet article fait parti d’une série pour apprendre le PHP en mode 20/80. Cliquez ici pour vous rendre sur le premier article.

Quels sont les signes qui m’indiquent que je dois revoir la structure de mon site

C’est simple, lorsque vous avez de plus en plus de mal à ajouter des fonctionnalités à votre page/site, c’est que vous approchez des limites l’organisation que vous avez choisi. Mais voici quelques exemples légèrement plus précis :

  • Lorsque le code ressemble à un plat de spaghetti
  • Lorsqu’il faut scroller 1 min avant de trouver la ligne à éditer
  • Lorsqu’il faut relire une fonction pour comprendre ce qu’elle fait
  • Lorsque l’on commence à confondre 2 classes

Dans ces moments-là, il devient urgent de structurer son code !

Si vous avez déjà un projet en plusieurs fichiers, passez directement au chapitre sur l’architecture MVC. Si vous connaissez déjà cette architecture, passez au chapitre suivant : la méthode SOLID. Sinon, on commence par le début 🙂

Inclure un fichier avec “include” et “inclure_once”

En PHP, il est possible de demander à notre programme de lire un autre fichier PHP. Prenons un exemple concret, nous parlions lors du cours précédent de créer un chat. Mais lorsqu’on commence à définir les fonctionnalités du chat, des messages et des utilisateurs (pour faire simple) dans un seul fichier, ça devient imbuvable.

On voudra alors mettre la gestion du chat dans un fichier, la gestion des messages dans un autre et la gestion des utilisateurs dans un dernier.

Pour cela, PHP pour propose les mots clé “include” et “include_once

include

Un exemple vaut mille mots !

<?php

/* fichier a include : fonction.php */
echo basename(__FILE__) . "<br />";

function afficherVariable($var) {
echo $var;
}
?>

<?php
/* fichier : index.php */
include "fonction.php";
afficherVariable("coucou");
?>

Include

Grâce au mot clé “include“, vous pouvez désormais commencer à découper votre code.

include_once

Une nouvelle fois, un exemple vaut mieux que mille mots :

<?php

/* fichier a include : fonction-supplementaire.php */
echo basename(__FILE__) . "<br />";

function afficheTailleVariable($var) {
echo size($var);
}
?>

<?php

/* fichier a include : fonction.php */
echo basename(__FILE__) . "<br />";

function afficherVariable($var) {
echo $var;
}
?>

</span>

<?php
/* fichier : index.php */
include "fonction.php";
afficherVariable("coucou");
?>

Ce qui donne !!

Avez-vous compris le problème ? PHP nous indique la fonction “afficherTailleVariable” a déjà été déclarée.

Je vous laisse chercher un instant. Trouvé ?

Et bien nous avons inclus les fichiers “fonction.php” et “fonction-supplementaire.php” depuis le fichier “index.php”.
Mais nous avons aussi inclus “fonction-supplementaire.php” depuis le fichier “fonction.php”.

Ce qui signifie que l’on inclus “fonction-supplementaire.php” deux fois, donc nous déclarons bien la fonction afficherTailleVarble() à deux reprises. Nous utilisons de ce fait include_once :

Celui-ci a exactement le même fonctionnement que son homologue “include“, mais a la particularité de demander à PHP de ne pas inclure le fichier si celui-ci a déjà était inclus. Ce qui est pratique lorsque notre fichier ne fait pas que des définitions d’objet, mais qu’il effectue une action, cela permet de ne pas la faire deux fois.

Note : En règle générale, il est préférable d’utiliser “include_once” pour éviter tout double inclusion.

Quelle architecture utiliser MVC ?

Maintenant que vous savez comment découper votre code PHP en plusieurs fichiers. Voyons où chaque partie de code PHP doit aller afin de garder un code cohérent et facile à tenir à jour.

Pour cela, je vous propose l’architecture MVC pour : Model, View, Controller. Je rajouterai même les Services

  • Les modèles (Model)
    Ce sont les fichiers contenant les fonctions qui s’occupent de faire le lien entre votre site et la base de données.
  • Les vues (View)
    S’occupent uniquement de l’affichage.
  • Les contrôleurs (Controller)
    Ce sont les fichiers qui contiennent les fonctions qui s’occupe de faire le lien entre le code logique (services) et le graphique (vues). Ils ne s’occupent que de formater les informations quand il y a besoin.
  • Les services
    Ceux-là s’occupent de toute la logique de votre page. C’est ici que l’on place les algorithmes.

Je reviendrai en détails dans un prochain article.

Les principes de base de la programmation  : SOLID

Dans le domaine de la programmation, SOLID est un acronyme représentant les cinq principes de bases pour la programmation orientée objet. Ils apportent une ligne directrice permettant le développement de logiciel plus fiable et plus robuste.

Ces principes proviennent des problèmes les plus récurrents dans le monde du développement. Plus vous les respecterez, et plus facile sera le développement de votre site/projet.

Responsabilité unique (single responsibility principle)

Une classe, une fonction ou une méthode doit avoir une et une seule responsabilité.

Si vous commencez à mélanger plusieurs fonctionnements, c’est que vous ne respectez pas ce principe.

Une astuce simple pour le savoir :

  • Avez-vous du mal à donner un nom clair à votre fonction ?
  • Pouvez-vous couper votre fonction en deux ?

Ouvert/fermé (open/closed principle)

Une classe doit être ouverte à l’extension, mais fermée à la modification.

Cela signifie qu’une fois que vous avez terminé d’écrire votre classe, vous ne devriez JAMAIS avoir à la modifier pour y ajouter des fonctionnalités. Pour cela, il vous faut apprendre à créer des extensions, avec de l’héritage par exemple.

Un astuce simple pour savoir si vous respectez ce principe :

  • Devez-vous régulièrement revenir pour éditer une classe ou une fonction ?
  • Vous arrive-t-il de créer des effets de bord, car plusieurs partie de code utilise la même class ou fonction et qui présente des dysfonctionnement à chaque fois que vous modifier quelque chose.

Si vous répondez oui à l’une de ces questions, c’est que vous ne respectez pas ce principe. A vous de jouer 😉

Substitution de Liskov (Liskov substitution principle)

Une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme.

Nous rentrons ici dans un sujet plus complexe, mais je vais essayer de l’expliquer plus clairement. L’héritage signifie qu’une classe hérite des propriétés d’une autre. Un exemple :

Animal > Chien > Caniche (ne me demandez pas pourquoi caniche… je ne sais pas.)

Le caniche est un chien. Notre classe Caniche hérite donc des informations qui définissent un chien.
Un chien est un animal. Notre classe Chien hérite donc lui des informations qui définissent un animal.

Dans ce principe, nous indiquons que si nous utilisons un “Animal” dans notre code, et que finalement, nous utilisons un “Chien” ou un “Caniche”, cela ne doit pas perturber la cohérence du code.

A l’inverse, si nous fournissons une classe “Maison”, il est clair que le programme ne va pas comprendre. Il n’y a pas de cohérence entre “Animal” et “Maison”.

Ségrégation des interfaces (interface segregation principle)

Préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale.

Un manager m’a dit une fois : “Il vaut mieux plein de petits bouts de code simples qu’un gros bout compliqué”. Et il a bien raison.

Je pense qu’il n’y a pas grand chose à dire ici. Si vous voyez que votre code souhaite prendre en charge trop de cas, et surtout pour des objectifs (client par exemple) différents, il est préférable de faire une extension pour chacun d’entre eux.

Par exemple, pour un processeur de paiement, au lieu d’avoir une classe contenant :

  • payer avec Stripe
  • payer avec Paypal
  • payer avec clickbank
  • etc.

Il est préférable de créer une interface (classe) “Paiement” qui dit : mes enfant auront la méthode “payer”. Vous pourrez ensuite créer une class PaiementPaypal qui hérite de la classe Paiement.

Inversion des dépendances (dependency inversion principle)

Il faut dépendre des abstractions, pas des implémentations.

C’est un peu plus compliqué pour celui-ci, ce n’est pas du 20/80. Je vous autorise donc à le passer 😉

Ce qu’il faut retenir en mode 20/80

L’architecture de votre code influencera rapidement de la qualité et la maintenance de celui-ci. Dès que vous sentez des difficultés à ajouter des fonctionnalités, c’est que vous devez revoir l’un des points précédemment cités.

Utilisez le plus tôt possible une architecture de type MVC, c’est-à-dire en séparant les types de besoin : logique, affichage, données. Et appliquez dès que possible les 5 principes SOLID !

 

Voilà, j’espère que cet article vous aura plu,
Si vous avez des questions, dites-le dans les commentaires, je répondrai avec plaisir !

  •  
  •  
  •  
  •  
  • 1
  •  
  •  
  •