2. IL N’Y A PAS DE FORMULE
MAGIQUE, les conseils suivants
ne sont pas à prendre à la lettre,
et rien ne dispense jamais de
réfléchir avant d’architecturer
quelque chose.
3. Instancier les objets le plus tôt possible
(+) Meilleur contrôle de l'instanciation (passage de
paramètres)
(+) Meilleur contrôle de l'injection
(+) Moins de magie (pas d'inflection)
(+) Moins de code (= moins de bugs !)
Exemple:
pas bien: $obj->addFoo('fooObject');
bien: $obj->addFoo(new fooObject());
Factory / Proxy
$obj->setFooFactory(new fooFactory());
4. Utiliser des factory ou des proxy
Retarder l'instanciation des "vrais" objets jusqu'à ce que ce
soit nécessaire
(+) Permet d'éviter de flinguer l'interface d'un objet parce
qu'on à pas les bonnes données au bon moment
exemple: injectors
(-) Plus de code (= plus de bugs)
(+) mais c'est facile à tester unitairement
(-) Moins facile de retrouver les utilisations d'un objet dans
le codebase
5. Éviter les $this->getFoobar()
Préferrer le passage d'argument
Dans les méthodes privées surtout
(+) Moins d'interactions avec l'environnement = moins
d'effets de bord
(+) Plus facile à tester
(+) Signature plus explicite
(-) Signature qui tend vers l'illisible
(-) risque de mélange arguments / accès internes
moins de lisibilité
6. Éviter les $this->getFoobar()
exemple: baseSimulation
Interface publique: baseSimulation#getTables()
Pas d'arguments
Accès internes
Facile à utiliser
Toutes les méthodes privées
Passage d'arguments
7. La composition, ça existe
Souvent une bonne alternative à l'héritage
(+) Permet la réutilisation horizontale
(+) Permet la "Separation of concerns"
8. Composition vs Héritage
<?php
class Voiture {}
class VoitureElectrique extends Voiture {}
class VoitureAEssence extends Voiture {}
class VoitureElectriqueVitresElectriques extends
VoitureElectrique {}
class VoitureAEssenceVitresElectriques extends VoitureAEssence {}
// wtf ?
9. Composition vs Héritage
<?php
class Voiture
{
public function __construct($moteur, $vitres) { }
}
new Voiture(new MoteurElectrique(), new VitresElectriques());
new Voiture(new MoteurAEssence(), new VitresElectriques());
// o/
10. Comment savoir ?
Une poire est un fruit
class Pear extends Fruit { }
Une voiture a un moteur
new Voiture(new Moteur());
11. Limiter les méthodes des interfaces
"Separation of concerns": une tâche, un objet
(+) Interfaces plus facile à comprendre
(+) Plus facile à réutiliser
(+) Plus facile à maintenir
(+) Plus facile à tester
12. Méthodes atomiques
(+) Plus facile à tester
(+) Plus facile à surcharger
(+) Plus facile à comprendre
(+) Plus facile à maintenir
13. Faciliter le testing
Le testing est le premier cas de réutilisation d'un objet
ergo, pas testable = pas réutilisable
(+) Un objet intestable est (souvent) un objet mal foutu
(-) Ne pas tomber dans le travers de "coder pour le test
unitaire"
14. Design only what you need
Si y'en a pas besoin, on le fait pas
ControleInfosRssCollectionFromObjects
(+) Moins de code
15. Éviter de retourner du "mixed"
"Principle of least astonishment"
exemple: retourner null au lieu d'un array vide
Desfois c'est logique
exemple: null|Object doSelectOne()
16. Nommer ses variables correctement
exemple (réels): $a, $soyons_cool, $onsenfiche
En cas de doute: demandez à un collègue
17. Appliquer la loi de Demeter
http://en.wikipedia.org/wiki/Law_of_Demeter
Pas bien:
public function doBlah()
{
$this->getFoobar()->getQuux()->doBlah();
}
Bien:
public function doBlah(Quux $quux)
{
$quux->doBlah();
}
18. Plus globalement: be SOLID
http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
Single responsibility principle
the notion that an object should have only a single responsibility.
Open/closed principle
the notion that “software entities … should be open for extension, but closed for modification”.
Liskov substitution principle
the notion that “objects in a program should be replaceable with instances of their subtypes without altering the
correctness of that program”.
Interface segregation principle
the notion that “many client specific interfaces are better than one general purpose interface.”
Dependency inversion principle
the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”
