Embed Size (px)
DESCRIPTION
Présentation pour l'AFUP des Traits sous PHP 5.4
Citation preview
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
