Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Les bonnes pratiques de l'architecture

Les bonnes pratiques de l'architecture

Internal talk, may contain things specific to our codebase :)

88b8138397e1d1441f4e4a54348bde09?s=128

ubermuda

March 30, 2011
Tweet

More Decks by ubermuda

Other Decks in Technology

Transcript

  1. Les bonnes pratiques de l'architecture en général Geoffrey Bachelet (@ubermuda)

  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.”
  19. Apprenez l'anglais ! c'est important.

  20. Documentez-vous Beaucoup de problèmes ont déjà été résolus (Design Patterns)

    Beaucoup de concepts ont déjà été discutés
  21. Nous sommes une équipe Deux cerveaux valent mieux qu'un Deux

    mémoires valent mieux qu'une
  22. PMSIpilot recrute ! wait...