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

Les bonnes pratiques

de l'architecture en général

Geoffrey Bachelet (@ubermuda)

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.

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());

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

Éviter les $this->getFoobar()

Préferrer le passage d'argumentDans 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é

Éviter les $this->getFoobar()

exemple: baseSimulation

Interface publique: baseSimulation#getTables()Pas d'argumentsAccès internesFacile à utiliser

Toutes les méthodes privéesPassage d'arguments

La composition, ça existe

Souvent une bonne alternative à l'héritage(+) Permet la réutilisation horizontale(+) Permet la "Separation of concerns"

Composition vs Héritage

<?php

class Voiture {}

class VoitureElectrique extends Voiture {}

class VoitureAEssence extends Voiture {}

class VoitureElectriqueVitresElectriques extends VoitureElectrique {}

class VoitureAEssenceVitresElectriques extends VoitureAEssence {}

// wtf ?

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/

Comment savoir ?

Une poire est un fruitclass Pear extends Fruit { }

Une voiture a un moteurnew Voiture(new Moteur());

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

Méthodes atomiques

(+) Plus facile à tester(+) Plus facile à surcharger(+) Plus facile à comprendre(+) Plus facile à maintenir

Faciliter le testing

Le testing est le premier cas de réutilisation d'un objetergo, 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"

Design only what you need

Si y'en a pas besoin, on le fait pasControleInfosRssCollectionFromObjects

(+) Moins de code

Éviter de retourner du "mixed"

"Principle of least astonishment"exemple: retourner null au lieu d'un array vide

Desfois c'est logiqueexemple: null|Object doSelectOne()

Nommer ses variables correctement

exemple (réels): $a, $soyons_cool, $onsenfiche En cas de doute: demandez à un collègue

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();}

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 principlethe notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”.

Interface segregation principlethe notion that “many client specific interfaces are better than one general purpose interface.”

Dependency inversion principlethe notion that one should “Depend upon Abstractions. Do not depend upon concretions.”

Apprenez l'anglais !

c'est 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 qu'unDeux mémoires valent mieux qu'une

PMSIpilot recrute !

wait...