DESIGN PATTERNS ET
DESIGN EMERGEANT
Tarik Zakaria Benmerar
Acigna Inc.
LES PRINCIPES DE LA
CONCEPTION DES
LOGICIELS
DRY
( DON’T REPEAT YOURSELF )
Chaque connaissance dans le système doit avoir une représentation unique
et non ambigüe.
DRY:
• Réutilisez du code, ne le dupliquez pas.
• Choisissez des noms clairs.
• Choisissez le bon endroit pour le code.
DRY: <?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDB";
// Create connecti...
DRY: <?php
function retrieveGuests( $conn ) {
$sql = "SELECT id, firstname, lastname FROM MyGuests";
$result = $conn->quer...
SRP
( SINGLE RESPONSABILITY
PRINCIPLE )
Chaque code doit avoir une seule responsabilité. Le code doit être cohésive.
SRP: <?php
$conn = getConnection();
$guests = retrieveGuests( $conn );
showGuests( $guests );
closConnection( $conn );
?>
...
TDA
( TELL DON’T ASK )
Déclarez des actions, au lieu de se poser des questions.
TDA: ----------------------------------------------------------------------
<?php
function showGuests( $guests ) {
if( cou...
YAGNI
( YOU AREN’T GONNA NEED IT YET )
Ecrivez du code que vous avez besoin maintenant.
OCP
( OPEN CLOSE PRINCIPLE )
Ouvert pour l’extensibilité. Fermé pour la modification.
LSP
( LISKOV’S SUBTITUTION PRINCIPLE )
Utilisez l’héritage seulement si la vous signifiez la substitution des deux
classes...
LSP:
<?php
class Rectangle {
private $topLeft;
private $width;
private $height;
public function setHeight($height) {
$this...
DIP
( DEPENDENCY INVERSION
PRINCIPLE )
Inversement du contrôle des dépendances.
DIP: <?php
class Square {
private $rectangle
public function _construct() {
$this->rectangle = new Rectangle();
}
public f...
LE DESIGN PATTERN
DESIGN
PATTERN:
• Recettes prêtes pour des problèmes de
programmation orienté objet (Qui
répondent aux principes déjà disc...
DESIGN
PATTERN:
• 23 patterns
classiques.
3 CATÉGORIES DE
PATTERNS
• Créationnel.
• Instanciation d’objets.
• Structurel.
• Structures larges
d’objets et de classes...
DESIGN PATTERNS
CRÉATIONNELS:
• Factory : Créer des objets sans exposer la logique
d’instanciation.
• Abstract Factory : E...
DESIGN PATTERNS
STRUCTURELS:
• Adapter : Adapter une interface à une autre incompatible.
• Bridge : Séparer l’abstraction ...
DESIGN PATTERNS
COMPORTEMENTAUX:
• Chaine de Responsabilité : Définir une méthode pour faire
passer une requête à travers ...
DESIGN PATTERNS
COMPORTEMENTAUX:
• State : Encapsuler différents comportements pour la même
routine en se basant sur l’éta...
TOUT CELA EST BIEN, MAIS
CE N’EST QUE LE DÉBUT DE
L’HISTOIRE……
LE DESIGN EMERGEANT
(ET ARCHITECTURE
ÉVOLUTIONNAIRE)
LE DESIGN EMERGEANT:
• On ne peut pas prévoir les design patterns à utiliser, on les
découvre.
• Les patterns présentés so...
PRÉPARER L’ÉMERGENCE DU
DESIGN:
• Le code doit être expressif.
• Les responsables de l’architecture doivent coder eux auss...
QUELQUES CLASSIQUES À
LIRE !
Prochain SlideShare
Chargement dans…5
×

Design patterns et Design Emergeant - Micro Days - Modern Software Development -

775 vues

Publié le

Quels sont les principes d'une bonne conception de logiciel ? Quels sont les design patterns les plus importants ?
Comment assurer l'évolution de la conception ?

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

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

Aucune remarque pour cette diapositive

Design patterns et Design Emergeant - Micro Days - Modern Software Development -

  1. 1. DESIGN PATTERNS ET DESIGN EMERGEANT Tarik Zakaria Benmerar Acigna Inc.
  2. 2. LES PRINCIPES DE LA CONCEPTION DES LOGICIELS
  3. 3. DRY ( DON’T REPEAT YOURSELF ) Chaque connaissance dans le système doit avoir une représentation unique et non ambigüe.
  4. 4. DRY: • Réutilisez du code, ne le dupliquez pas. • Choisissez des noms clairs. • Choisissez le bon endroit pour le code.
  5. 5. DRY: <?php $servername = "localhost"; $username = "username"; $password = "password"; $dbname = "myDB"; // Create connection $conn = new mysqli($servername, $username, $password, $dbname); // Check connection if ($conn->connect_error) { die("Connection failed: " . $conn->connect_error); } $sql = "SELECT id, firstname, lastname FROM MyGuests"; $result = $conn->query($sql); if ($result->num_rows > 0) { // output data of each row while($row = $result->fetch_assoc()) { echo "id: " . $row["id"]. " - Name: " . $row["firstname"]. " " . $row["lastname"]. "<br>"; } } else { echo "0 results"; } $conn->close(); ?>
  6. 6. DRY: <?php function retrieveGuests( $conn ) { $sql = "SELECT id, firstname, lastname FROM MyGuests"; $result = $conn->query($sql), $resultArr = []; if ($result->num_rows > 0) { while($row = $result->fetch_assoc()) { $resultArr[] = $row; } } return $resulArr; } ?> Le code sera placée dans guests/models.php
  7. 7. SRP ( SINGLE RESPONSABILITY PRINCIPLE ) Chaque code doit avoir une seule responsabilité. Le code doit être cohésive.
  8. 8. SRP: <?php $conn = getConnection(); $guests = retrieveGuests( $conn ); showGuests( $guests ); closConnection( $conn ); ?> ---------------------------------------------------------------------- <?php function showGuests( $guests ) { if( count( $guests ) ) { for( $i = 0; $i < count( $guests ); $i++ ) { $row = $guests[ i ]; echo "id: " . $row["id"]. " - Name: " . $row["firstname"]. " " . $row["lastname"]. "<br>"; } } else { echo "0 results"; } } ?>
  9. 9. TDA ( TELL DON’T ASK ) Déclarez des actions, au lieu de se poser des questions.
  10. 10. TDA: ---------------------------------------------------------------------- <?php function showGuests( $guests ) { if( count( $guests ) ) { foreach( $guests as $row ) { echo "id: " . $row["id"]. " - Name: " . $row["firstname"]. " " . $row["lastname"]. "<br>"; } } else { echo "0 results"; } } ?> ----------------------------------------------------------------------- var numbers = [….]; numbers.some(function ( number ) { return !numbers % 2; });
  11. 11. YAGNI ( YOU AREN’T GONNA NEED IT YET ) Ecrivez du code que vous avez besoin maintenant.
  12. 12. OCP ( OPEN CLOSE PRINCIPLE ) Ouvert pour l’extensibilité. Fermé pour la modification.
  13. 13. LSP ( LISKOV’S SUBTITUTION PRINCIPLE ) Utilisez l’héritage seulement si la vous signifiez la substitution des deux classes (parent et fils).
  14. 14. LSP: <?php class Rectangle { private $topLeft; private $width; private $height; public function setHeight($height) { $this->height = $height; } public function getHeight() { return $this->height; } public function setWidth($width) { $this->width = $width; } public function getWidth() { return $this->width; } public function area() { return $this->width * $this->height; } } ?> <?php class Square extends Rectangle { public function setHeight($height) { $this->height = $height; $this->widget = $height; } public function setWidth($width) { $this->width = $width; $this->height = $width; } } ?> <?php class Square { private $rectangle public function setSide( $side ) { $this->rectangle->setWidth( $side ); $this->rectangle->setHeight( $side ); } public function area() { return $this->rectangle->area(); } } ?>
  15. 15. DIP ( DEPENDENCY INVERSION PRINCIPLE ) Inversement du contrôle des dépendances.
  16. 16. DIP: <?php class Square { private $rectangle public function _construct() { $this->rectangle = new Rectangle(); } public function setSide( $side ) { $this->rectangle->setWidth( $side ); $this->rectangle->setHeight( $side ); } public function area() { return $this->rectangle->Area(); } } ?> <?php class Square { private $rectangle public function _construct( $rectangle ) { $this->rectangle = $rectangle; } public function setSide( $side ) { $this->rectangle->setWidth( $side ); $this->rectangle->setHeight( $side ); } public function area() { return $this->rectangle->Area(); } } ?>
  17. 17. LE DESIGN PATTERN
  18. 18. DESIGN PATTERN: • Recettes prêtes pour des problèmes de programmation orienté objet (Qui répondent aux principes déjà discutés). • Reutilisation de code : pas de reinvention de la rue. • Assurer un langage commun. • Applicable à un contexte.
  19. 19. DESIGN PATTERN: • 23 patterns classiques.
  20. 20. 3 CATÉGORIES DE PATTERNS • Créationnel. • Instanciation d’objets. • Structurel. • Structures larges d’objets et de classes. • Comportemental. • Interaction et distribution de responsabilités.
  21. 21. DESIGN PATTERNS CRÉATIONNELS: • Factory : Créer des objets sans exposer la logique d’instanciation. • Abstract Factory : Encapsulation d’une famille de factories qui produit des familles d’objets. • Builder : Séparation de la construction d’un objet complexe de sa représentation. • Singleton : Assurer qu’une seule instance d’une classe existe tout en fournissant une seule méthode pour accéder cette instance. • Prototype : Créer une instance initialisée pour clonage. • Object Pool : Réutilisation et partage d’objets coûteux à créer.
  22. 22. DESIGN PATTERNS STRUCTURELS: • Adapter : Adapter une interface à une autre incompatible. • Bridge : Séparer l’abstraction de l’implémentation. • Composite : Composer les objets dans une structure d’arbres. • Decorator : Ajouter de nouveaux comportements de façon dynamique ou statiques. • Facade : Simplifier l’utilisation en définissant une interface de haut niveau. • Flyweight : Partager une partie des états d’objets. • Proxy : Créer une référence à un autre objet (pouvant être distant).
  23. 23. DESIGN PATTERNS COMPORTEMENTAUX: • Chaine de Responsabilité : Définir une méthode pour faire passer une requête à travers une chaine d’objets. • Commande : Encapsuler une requête type commande dans un objet. • Interpreter : Spécifier comment interpréter un langage. • Iterator : Accéder aux éléments d’une conteneur. • Mediator : Centralisation du mécanisme de communication entre les objets. • Memento : Permettre la récupération des états antérieurs. • Observer : Notifier plusieurs objets du changement d’état d’un objet particulier.
  24. 24. DESIGN PATTERNS COMPORTEMENTAUX: • State : Encapsuler différents comportements pour la même routine en se basant sur l’état de l’objet. • Strategy : Séparer l’implémentation de l’algorithme de son utilisation. • Template Method : Définir le squelette d’un algorithme dans une opération, différer certaines étapes dans les sous- classes. • Visitor : Séparer un algorithme de la structure d’objet sur lequel il opère. • Null Object : Définir un objet avec un comportement neutre.
  25. 25. TOUT CELA EST BIEN, MAIS CE N’EST QUE LE DÉBUT DE L’HISTOIRE……
  26. 26. LE DESIGN EMERGEANT (ET ARCHITECTURE ÉVOLUTIONNAIRE)
  27. 27. LE DESIGN EMERGEANT: • On ne peut pas prévoir les design patterns à utiliser, on les découvre. • Les patterns présentés sont de nature technique, alors qu’il existe des patterns du domaine. • Le logiciel en lui-même change d’objectif et de structure, de fait de plusieurs facteurs de l’environnement.
  28. 28. PRÉPARER L’ÉMERGENCE DU DESIGN: • Le code doit être expressif. • Les responsables de l’architecture doivent coder eux aussi. • Séparer l’architecture (difficile à changer) du design (assez flexible pour être changé). • Les décisions définitives de la conception doivent être faits le plus tard possible. • Choisissez un framework qui est découplé et qui respecte les principes de la bonne conception. • Comprendre le domaine d’étude. • Adopter le TDD (Un programme difficile à tester implique à un certain niveau une mauvaise conception).
  29. 29. QUELQUES CLASSIQUES À LIRE !

×