Programmation orientée ObjetVers php 5.4
Réduire le couplage applicatif grâce aux Traits
(mauvaise) définition scolaire de l'objet
• Un objet est une représentation concrète d'un concept abstrait
Une classe
• Contient des attributs et des méthodes dont la portée peut être limitée
• Un seul héritage pour n interfaces
• Une méthode est identifiée par sa signature
La signature/**
* description de la méthode
*
* @access public
* @param integer $nombre
* @return string
*/
public function example($nombre) {
return "une chaîne";
}
L'interface• Permet de s'assurer que les objets manipulés
fonctionnent de la même manière
=> Contrat
Public fonction utilise(interfaceStylo $stylo) {
}
La Php Standard Library
• Ou SPL
• Permet d'ajouter des fonctionnalités à des objets
• Exemple : l'interface countable
Class CountMe implements Countable {
Public fonction count() {
Return 5;
}
}
$object = new CountMe;
echo sizeof($object); // 5
FailUn objet c'est pas ça !
Pas une représentation concrète
• On n'a jamais vu un "lanceur de requête Sql" dans la vraie vie
Repenser la définition d'un objet
Un objet est un comportement
• Un objet est un comportement vis à vis de données
• L'agrégat des comportements constitue une application
L'héritage
• Spécialisation d'un comportement
• Une classe fille peut réutiliser ou spécialiser le comportement de sa classe mère
• Pas d'héritage multiple en PHP
L'héritage échouePour 2 raisons
1/ spécialiser n'est pas décliner
• Souvent on ne spécialise pas, on décline
• C'est infini !
2/ l'héritage "outil"• L'héritage ne doit pas permettre de donner des outils
Class Example extends Singleton {}
=> ça ne doit pas exister !!
Le couplage applicatif(petit détour)
Code spagethi
• Dépendances fortes entre les composants
• Tout est entremêlé
• Maintenabilité faible
le couplage applicatif• Principe SOLID
• Single Responsability
• Open / closes
• Liskov substitution
• Interface segregation
• Dépendency inversion
Couplage faible
Horizontalité vs Verticalité• Un modèle vertical (type héritage mal conçu) n'est
pas maintenable
• Penser horizontal :
• Pattern Strategy
• Injection de dépendance
Les Traits(pas trop tôt)
Blocs de comportement• Réutilisables
• Modèle orienté collaboration
Class Example {
Use Trait1, Trait2;
}
À l'origine : les mixins
• Composants liés à la réutilisation plutôt qu'à l'instanciation
• Sont mélangés au code (mixed-in)
• Injectés dans le code au moment de l'héritage
• Conflits entre les mixins
Les Traits
• Réutilisation de fonctionnalités au niveau des classes
• L'ensemble des méthodes d'un Trait constituent son comportement
• Sans État
Gestion des conflits• Pas de priorité implicite
Class Example {
Use Trait1, Trait2 {
Trait2::myMethod as m;
Trait1::any insteadof Trait2
}
}
• Résolution explicite des conflits
Traits composites
• Un Trait peut être composé d'autres Traits
• On parle alors de Traits composites
Trait Singleton {
/**
* Constructor
*/
protected function __construct() {}
/**
* Get singleton instance
* @return static
*/
public static function getInstance() {
static $instance = null;
if (is_null($instance)) {
$instance = new static;
}
return $instance;
}
/**
* Prevents cloning
* @throws Exception
*/
public function __clone() {
throw new \Exception('Cloning of this object isn\'t authorized');
}
/**
* Prevents deserialization
* @throws Exception
*/
public function __wakeup() {
throw new \Exception("Cannot deserialize instance of Singleton pattern in" . get_called_class());
}
}
class Example extends MaClasseMetier {
use \Singleton;
}
$oExample = Example::getInstance();
var_dump($oExample === Example::getInstance());
// true
$oExample = new Example;
// Fatal error: Call to protected Example::__construct() from invalid context
Et c'est pas plus lent
1130
1135
1140
1145
1150
heritage 1 trait 4 traits
Liens et ressources
Sur le netRFC des traits : https://wiki.php.net/rfc/horizontalreuse
Recherches d'Alexandre Bergel : http://bergel.eu
Questions