Synolab

PHP Objet – Héritage conditionnel

Par Damien L. le 13 juillet 2016

 Lecture 2 minutes

Nous allons parler ici de l'héritage conditionnel. Derrière ce nom barbare se cache une astuce de modularité très puissante.

La plupart des frameworks proposent des mécaniques d'override (ou fallback, ou extension, ou ...). Cela répond au besoin de pouvoir remplacer une brique de l'application par une autre. Et par "brique", on entend "classe".

Ce type d'altération peut être mis en place via différents systèmes :

  • Pattern Décorateur
  • Polymorphisme classique
  • Polymorphisme lié au framework
  • ...

Nous allons nous attarder au polymorphisme de manière générale. L'idée est simple : on étend (extend) la classe dont le comportement est à altérer, et on réécrit le code qui nous intéresse (le plus souvent le tout est accompagné d'un jeu de fichiers de configurations).

Le cadre étant posé, voici le cas à étudier :

Supposons une application, dont on souhaite réécrire une classe, mais dont cette dernière est potentiellement déjà réécrite. Exemple : dans Magento 1, la classe "Mage_Catalog_Block_Layer_View", dans la version Community est déjà réécriture par "Enterprise_Search_Block_Catalog_Layer_View" dans la version enterprise. Si l'on souhaite développer un module compatible avec les deux versions, il faut donc pouvoir hériter, selon le cas, de telle ou telle classe.

Une image étant toujours plus claire que de longs discours, voici une représentation UML de la chose :

UML représentatif de l'héritage conditionnel

  • RewriteObject : La classe qui doit hériter de Parent1 OU Parent2
  • RewriteAdapter : La classe qui va décider de l'héritage
  • Parent1 et Parent2 : Les classes dont on doit hériter de manière conditionnelle

Nous n'allons pas nous attarder sur RewriteObject, Parent1 et Parent2, qui sont des classes sans particularité.

En revanche, que contient RewriteAdapter ?

 

C'était aussi simple que ça.

Damien L.

Geek sans barbe qui aime le rock, la bière, et les Design Patterns !

GIF