1. Programmation orientée Objet
Vers php 5.4

2. Réduire le couplage
applicatif grâce aux Traits

3. (mauvaise) définition scolaire de l'objet
• Un objet est une
représentation concrète d'un
concept abstrait

4. 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

5. La signature
/**
* description de la méthode
*
* @access public
* @param integer $nombre
* @return string
*/
public function example($nombre) {
return "une chaîne";
}

6. L'interface
• Permet de s'assurer que les objets manipulés
fonctionnent de la même manière
=> Contrat
Public fonction utilise(interfaceStylo $stylo) {
}

7. La Php Standard Library
Class CountMe implements Countable {
Public fonction count() {
Return 5;
• Ou SPL
}
• Permet d'ajouter des fonctionnalités à des objets
}
$object = new CountMe;
• Exemple : l'interface countable
echo sizeof($object); // 5

8. Fail
Un objet c'est pas ça !

9. Pas une représentation concrète
• On n'a jamais vu un "lanceur de requête Sql" dans la
vraie vie

10. Repenser la définition d'un objet

11. Un objet est un comportement
• Un objet est un comportement vis à vis de
données
• L'agrégat des comportements constitue une
application

12. 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

13. L'héritage échoue
Pour 2 raisons

14. 1/ spécialiser n'est pas décliner
• Souvent on ne spécialise
pas, on décline
• C'est infini !

15. 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 !!

16. Le couplage applicatif
(petit détour)

17. Code spagethi
• Dépendances fortes entre les
composants
• Tout est entremêlé
• Maintenabilité faible

18. le couplage applicatif
• Principe SOLID
• Single Responsability
• Open / closes
• Liskov substitution
Couplage faible
• Interface segregation
• Dépendency inversion

19. 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

20. Les Traits
(pas trop tôt)

21. Blocs de comportement
• Réutilisables
• Modèle orienté collaboration
Class Example {
Use Trait1, Trait2;
}

22. À 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

23. Les Traits
• Réutilisation de fonctionnalités au niveau des
classes
• L'ensemble des méthodes d'un Trait constituent son
comportement
• Sans État

24. Gestion des conflits
• Pas de priorité implicite
Class Example {
Use Trait1, Trait2 {
Trait2::myMethod as m;
• Résolution explicite
Trait1::any insteadof Trait2
des conflits
}
}

25. Traits composites
• Un Trait peut être composé d'autres Traits
• On parle alors de Traits composites

26. Trait Singleton {
/**
/**
* Constructor
* Prevents cloning
*/
* @throws Exception
protected function __construct() {}
*/
/**
public function __clone() {
* Get singleton instance
throw new Exception('Cloning of this object isn't
* @return static
authorized');
*/
}
public static function getInstance() {
/**
static $instance = null;
* Prevents deserialization
if (is_null($instance)) {
* @throws Exception
$instance = new static;
*/
}
public function __wakeup() {
return $instance;
throw new Exception("Cannot deserialize instance
of Singleton pattern in" . get_called_class());
}
}
}

27. 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

28. Et c'est pas plus lent
1150
1145
1140
1135
1130
heritage 1 trait 4 traits

29. Liens et ressources

30. Sur le net
RFC des traits : https://wiki.php.net/rfc/horizontalreuse
Recherches d'Alexandre Bergel : http://bergel.eu

31. Questions