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

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

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

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 );
?>
----------------------------------------------------------------------
<?php
function showGuests( $guests ) {
if( count( $guests ) ) {
for( $i = 0; $i < count( $guests ); $i++ ) {
$row = $guests[ i ];
}
} else {
echo "0 results";
}
}
?>

TDA
( TELL DON’T ASK )
Déclarez des actions, au lieu de se poser des questions.

TDA: ----------------------------------------------------------------------
<?php
function showGuests( $guests ) {
if( count( $guests ) ) {
foreach( $guests as $row ) {
}
} else {
echo "0 results";
}
}
?>
-----------------------------------------------------------------------
var numbers = [….];
numbers.some(function ( number ) {
return !numbers % 2;
});

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 (parent et fils).

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 );
}
return $this->rectangle->area();
}
}
?>

DIP
( DEPENDENCY INVERSION
PRINCIPLE )
Inversement du contrôle des dépendances.

DIP: <?php
class Square {
private $rectangle
public function _construct() {
$this->rectangle = new Rectangle();
}
}
return $this->rectangle->Area();
}
}
?>
<?php
class Square {
private $rectangle
public function _construct( $rectangle ) {
$this->rectangle = $rectangle;
}
}
return $this->rectangle->Area();
}
}
?>

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.

DESIGN
PATTERN:
• 23 patterns
classiques.

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.

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.

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).

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.

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.

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 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.

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).

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

Contenu connexe

Tendances

En vedette

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

Plus de Tarik Zakaria Benmerar

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