Les bonnes pratiques    de larchitecture en généralGeoffrey Bachelet (@ubermuda)
IL N’Y A PAS DE FORMULEMAGIQUE, les conseils suivantsne sont pas à prendre à la lettre,  et rien ne dispense jamais de réf...
Instancier les objets le plus tôt possible  (+) Meilleur contrôle de linstanciation (passage de  paramètres)  (+) Meilleur...
Utiliser des factory ou des proxy  Retarder linstanciation des "vrais" objets jusquà ce que ce  soit nécessaire  (+) Perme...
Éviter les $this->getFoobar()  Préferrer le passage dargument  Dans les méthodes privées surtout  (+) Moins dinteractions ...
Éviter les $this->getFoobar()exemple: baseSimulationInterface publique: baseSimulation#getTables()    Pas darguments    Ac...
La composition, ça existe  Souvent une bonne alternative à lhéritage  (+) Permet la réutilisation horizontale  (+) Permet ...
Composition vs Héritage<?phpclass Voiture {}class VoitureElectrique extends Voiture {}class VoitureAEssence extends Voitur...
Composition vs Héritage<?phpclass Voiture{  public function __construct($moteur, $vitres) { }}new Voiture(new MoteurElectr...
Comment savoir ?  Une poire est un fruit      class Pear extends Fruit { }Une voiture a un moteur      new Voiture(new Mot...
Limiter les méthodes des interfaces  "Separation of concerns": une tâche, un objet  (+) Interfaces plus facile à comprendr...
Méthodes atomiques (+) Plus facile à tester (+) Plus facile à surcharger (+) Plus facile à comprendre (+) Plus facile à ma...
Faciliter le testing  Le testing est le premier cas de réutilisation dun objet      ergo, pas testable = pas réutilisable ...
Design only what you need  Si yen a pas besoin, on le fait pas      ControleInfosRssCollectionFromObjects  (+) Moins de code
Éviter de retourner du "mixed"  "Principle of least astonishment"      exemple: retourner null au lieu dun array vide  Des...
Nommer ses variables correctement  exemple (réels): $a, $soyons_cool, $onsenfiche  En cas de doute: demandez à un collègue
Appliquer la loi de Demeterhttp://en.wikipedia.org/wiki/Law_of_DemeterPas bien:public function doBlah(){  $this->getFoobar...
Plus globalement: be SOLIDhttp://en.wikipedia.org/wiki/Solid_(object-oriented_design)    Single responsibility principle  ...
Apprenez langlais !    cest important.
Documentez-vous Beaucoup de problèmes ont déjà été résolus (Design Patterns) Beaucoup de concepts ont déjà été discutés
Nous sommes une équipe Deux cerveaux valent mieux quun Deux mémoires valent mieux quune
PMSIpilot recrute !       wait...
Prochain SlideShare
Chargement dans…5
×

Les bonnes pratiques de l'architecture en général

4 105 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
4 105
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 404
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Les bonnes pratiques de l'architecture en général

  1. 1. Les bonnes pratiques de larchitecture en généralGeoffrey Bachelet (@ubermuda)
  2. 2. IL N’Y A PAS DE FORMULEMAGIQUE, les conseils suivantsne sont pas à prendre à la lettre, et rien ne dispense jamais de réfléchir avant d’architecturer quelque chose.
  3. 3. Instancier les objets le plus tôt possible (+) Meilleur contrôle de linstanciation (passage de paramètres) (+) Meilleur contrôle de linjection (+) Moins de magie (pas dinflection) (+) Moins de code (= moins de bugs !) Exemple: pas bien: $obj->addFoo(fooObject); bien: $obj->addFoo(new fooObject()); Factory / Proxy $obj->setFooFactory(new fooFactory());
  4. 4. Utiliser des factory ou des proxy Retarder linstanciation des "vrais" objets jusquà ce que ce soit nécessaire (+) Permet déviter de flinguer linterface dun objet parce quon à pas les bonnes données au bon moment exemple: injectors (-) Plus de code (= plus de bugs) (+) mais cest facile à tester unitairement (-) Moins facile de retrouver les utilisations dun objet dans le codebase
  5. 5. Éviter les $this->getFoobar() Préferrer le passage dargument Dans les méthodes privées surtout (+) Moins dinteractions avec lenvironnement = moins deffets de bord (+) Plus facile à tester (+) Signature plus explicite (-) Signature qui tend vers lillisible (-) risque de mélange arguments / accès internes moins de lisibilité
  6. 6. Éviter les $this->getFoobar()exemple: baseSimulationInterface publique: baseSimulation#getTables() Pas darguments Accès internes Facile à utiliserToutes les méthodes privées Passage darguments
  7. 7. La composition, ça existe Souvent une bonne alternative à lhéritage (+) Permet la réutilisation horizontale (+) Permet la "Separation of concerns"
  8. 8. Composition vs Héritage<?phpclass Voiture {}class VoitureElectrique extends Voiture {}class VoitureAEssence extends Voiture {}class VoitureElectriqueVitresElectriques extendsVoitureElectrique {}class VoitureAEssenceVitresElectriques extends VoitureAEssence {}// wtf ?
  9. 9. Composition vs Héritage<?phpclass Voiture{ public function __construct($moteur, $vitres) { }}new Voiture(new MoteurElectrique(), new VitresElectriques());new Voiture(new MoteurAEssence(), new VitresElectriques());// o/
  10. 10. Comment savoir ? Une poire est un fruit class Pear extends Fruit { }Une voiture a un moteur new Voiture(new Moteur());
  11. 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. 12. Méthodes atomiques (+) Plus facile à tester (+) Plus facile à surcharger (+) Plus facile à comprendre (+) Plus facile à maintenir
  13. 13. Faciliter le testing Le testing est le premier cas de réutilisation dun 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. 14. Design only what you need Si yen a pas besoin, on le fait pas ControleInfosRssCollectionFromObjects (+) Moins de code
  15. 15. Éviter de retourner du "mixed" "Principle of least astonishment" exemple: retourner null au lieu dun array vide Desfois cest logique exemple: null|Object doSelectOne()
  16. 16. Nommer ses variables correctement exemple (réels): $a, $soyons_cool, $onsenfiche En cas de doute: demandez à un collègue
  17. 17. Appliquer la loi de Demeterhttp://en.wikipedia.org/wiki/Law_of_DemeterPas bien:public function doBlah(){ $this->getFoobar()->getQuux()->doBlah();}Bien:public function doBlah(Quux $quux){ $quux->doBlah();}
  18. 18. Plus globalement: be SOLIDhttp://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. 19. Apprenez langlais ! cest important.
  20. 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. 21. Nous sommes une équipe Deux cerveaux valent mieux quun Deux mémoires valent mieux quune
  22. 22. PMSIpilot recrute ! wait...

×