Présentation au quatrième PHP meetup de Bordeaux sur la programmation STUPID versus SOLID.

1. PROGRAMMATION STUPID VS SOLID

2. QUI SUIS-JE ?
Arnaud Langlade / @_aRn0D
Développeur Symfony chez Clever Age
Sylius core team member / @Sylius
www.clever-age.com / @CleverAge

3. STUPID, KÉZAKO ?
Singleton
Tight coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

4. INSTANCES UNIQUES (SINGLETON)
class MyClass
{
public function __contruct()
{
$this­>connexion = Connexion::getInstance([
'dsn' => 'mysql:host=localhost;dbname=my_db'
])
}
}
Un singleton ne facilite pas la configuration des objets
Les singletons introduisent des couplages forts entre les objets
Pas vue globale sur l'application (les dépendences sont cachées)

5. COUPLAGE FORT (TIGHT COUPLING)
class MyClass
{
public function __construct()
{
$this­>connexion = new MyConnexion();
}
}
class MyClass
{
public function __construct(Connexion $connexion)
{
$this­>connexion = $connexion;
}
}
Difficulté dans la mise en place des tests
Impossible de créer des mocks
Dépendence forte entre composants

6. NON TESTABILITÉ (UNTESTABILITY)
Eviter les bogues et les régressions
Faciliter la refactorisation
Attention: Un code fortement couplé sera difficilement
testable

7. OPTIMISATIONS PRÉMATURÉES (PREMATURE OPTIMIZATION)
De simples applications peuvent se transformer en usine à gaz
Rend difficile :
la lecture et compréhension du code
la maintenance de votre application

8. NOMMAGE INDÉCHIFFRABLE (INDESCRIPTIVE NAMING)
class Quadrilateral
{
public function getOutline($a, $b)
{
return ($a + $b) * 2;
}
}
class Quadrilateral
{
public function getPerimeter($with, $height)
{
return ($with + $height) * 2;
}
}
Gain de temps lors de : la relecture, la maintenance et l’évolution
Eviter les abréviations ou d'acronymes est fortement conseillé

9. DUPLICATIONS (DUPLICATION)
Une modification de code entraîne :
la répercuter le changement à plusieurs endroits
la maintenance de l'application plus difficile
Des outils automatisent la détection des duplications
PHP Copy Paste Detector (PHPC)
SonarSource

10. SOLID, KÉZAKO ?
Michael Feathers et Robert C. Martin (aka Uncle Bob)
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

11. PRINCIPE DE RESPONSABILITÉ UNIQUE (SINGLE RESPONSIBILITY PRINCIPLE)
Une classe doit remplir un rôle précis

12. PRINCIPE DE RESPONSABILITÉ UNIQUE (SINGLE RESPONSIBILITY PRINCIPLE)
class DataImporter
{
public function import($file)
{
$this­>writeData(
$this­>loadFile($file)
);
}
private function loadData($file) { ... }
private function writeData(array $data) { ... }
}

13. PRINCIPE DE RESPONSABILITÉ UNIQUE (SINGLE RESPONSIBILITY PRINCIPLE)
class DataImporter
{
public function __construct(Loader $loader, Writer $writer)
{
$this­>loader = $loader;
$this­>writer = $writer;
}
public function import($file)
{
foreach($this­>loader­>load($file) as $item) {
$this­>writer­>write();
}
}
}

14. PRINCIPE DE RESPONSABILITÉ UNIQUE (SINGLE RESPONSIBILITY PRINCIPLE)
La classe est facilement testable
Facilite l’évolution des implémentations existantes
Facilite l'ajouter de nouvelles implémentations

15. PRINCIPE OUVERT / FERMÉ (OPEN/CLOSED PRINCIPLE)
Ce principe consiste à rendre les modules ouverts à l'extension et fermés aux
modifications

16. PRINCIPE OUVERT / FERMÉ (OPEN/CLOSED PRINCIPLE)
$importer = DataImporter(new CsvLoader(), new MysqlWriter());
$importer = DataImporter(new XMLLoader(), new MongoWriter());

17. PRINCIPE OUVERT / FERMÉ (OPEN/CLOSED PRINCIPLE)
class UserControler
{
public function createUser()
{
// Event pre_create
// Enregistrement de l'utilisateur
// Event post_create
}
}

18. PRINCIPE DE SUBSTITUTION DE LISKOV (LISKOV SUBSTITUTION PRINCIPLE)
Si la classe T a une dépendance de type S alors on doit pouvoir remplacer
cette dépendance par tous types dérivés de S.
Formulé par Barbara Liskov et Jeannette Wing

19. PRINCIPE DE SUBSTITUTION DE LISKOV (LISKOV SUBSTITUTION PRINCIPLE)
class CsvLoader implements LoaderInterface
{
public function load(File $file)
{
// ...
}
}
class XmlLoader implements LoaderInterface
{
public function load(File $file)
{
// ...
}
}
class DataImporter
{
public function load(LoaderInterface $loader, /* ... */)
{
// ...
}
}

20. PRINCIPE DE SUBSTITUTION DE LISKOV (LISKOV SUBSTITUTION PRINCIPLE)
Implique de conserver de la classe parente (surtout en PHP) :
les mêmes signatures des méthodes
la nature des valeurs de retour des méthodes
Diminution du couplage.

21. PRINCIPE DE SÉGRÉGATION D'INTERFACES (INTERFACE SEGREGATION PRINCIPLE)
Principe de responsabilité unique pour les interfaces

22. PRINCIPE D'INVERSION DE DÉPENDANCE (DEPENDENCY INVERSION PRINCIPLE)
Il faut dépendre des abstractions, pas des implémentations

23. PRINCIPE D'INJECTION/INVERSION DE DÉPENDANCE (DEPENDENCY INVERSION PRINCIPLE)
class DataImporter
{
public function __construct()
{
$this­>loader = new CsvLoader();
$this­>writer = new MysqlWriter();
}
}
class DataImporter
{
public function __construct(CsvLoader $loader, MysqlGateway $writer)
{
$this­>loader = $loader;
$this­>writer = $writer;
}
}

24. PRINCIPE D'INVERSION DE DÉPENDANCE (DEPENDENCY INVERSION PRINCIPLE)
class DataImporter
{
public function __construct(LoaderInterface $loader, WriterInterface $writer)
{
$this­>loader = $loader;
$this­>writer = $writer;
}
}

25. PRINCIPE D'INJECTION DE DÉPENDANCE (DEPENDENCY INVERSION PRINCIPLE)
Une nette diminution du couplage
Une meilleure encapsulation

26. MERCI! QUESTIONS ?
Arnaud Langlade
Twiter @_aRn0D
Sylius : www.sylius.org