OOP and Design Patterns

OOP&

DESIGN PATTERNTarik 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 connectionif ($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: <?phpfunction 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 );?>----------------------------------------------------------------------<?phpfunction 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"; } }

?>

TDA( TELL DON’T ASK )

Déclarez des actions, au lieu de se poser des questions.

TDA: ----------------------------------------------------------------------<?phpfunction 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;});

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 vous signifiez la substitution des deux classes (parent et fils).

LSP:<?phpclass 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; }}?>

<?phpclass Square extends Rectangle { public function setHeight($height) { $this->height = $height; $this->widget = $height; } public function setWidth($width) { $this->width = $width; $this->height = $width; } }?><?phpclass Square { private $rectangle

public function setSide( $side ) { $this->rectangle->setWidth( $side ); $this->rectangle->setHeight( $side ); }

public function area() { return $this->rectangle->area(); }}?>

DIP( DEPENDENCY INVERSION

PRINCIPLE )

Inversement du contrôle des dépendances.

DIP: <?phpclass 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(); }}?>

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

LE DESIGN PATTERN

DESIGNPATTERN:

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

DESIGNPATTERN:

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

Extracted vs. preemptive frameworksThe best frameworks tend to be those extracted from working code rather than preemptively designed. Someone sitting down to design a framework must anticipate all the ways developers might want to use it. The framework ends up including lots of features, with a high chance that any given user won't use all of them. But you still must take the unused features of your chosen framework into account, because they add to your applications' accidental complexity; this could mean doing something as simple as making extra entries in a configuration document, or as intrusive as changing the way you'd like to implement a feature. Preemptive frameworks tend to be giant buckets of features, with other (unanticipated) features left out. JavaServer Faces (JSF) is a classic example of a preemptive framework. One of its cool features is the ability to plug in different rendering pipelines, in case you want to emit a format other than HTML. Although this feature is used rarely, all JSF users must understand its impact on a JSF request's life cycle.Frameworks that grow from working applications tend to offer a more pragmatic set of features, because they address the actual problems someone faced when writing an application.

Extracted frameworks tend to have fewer extraneous features. Contrast a preemptive framework like JSF with an extracted framework like Ruby on Rails, which has grown from actual usage.

LE PATTERN DU DOMAINE(ANALYSIS PATTERN)

• Les Designs Patterns répondent à des problématiques purement techniques, et peuvent éventuellement s’appliquer à une conception d’un domaine d’étude (Finance, Sport, Recrutement, etc. ou Conception Orientée Domaine).

• Les Patterns du domaine reflètent des concepts profondes émergeant du domaine.

PATTERN DU DOMAINE :

MODÈLE DE COMPTABILITÉ AVEC UN SYSTÈME DE TRANSACTION

DOMAIN SPECIFIC LANGUAGE

• Language réduit pour définir et générer un modèle.• S’applique dans un cadre particulier du domaine.• Communique plus clairement l’objectif d’une partie du

système.• Améliore la communication avec les experts du

domaine. • Constitue un modèle alternative à une conception

purement orientée objet.• Exemples :• Grammaire d’un langage de programmation.• Automate à été fini.

DOMAIN SPECIFIC LANGUAGE :

QUELQUES CLASSIQUES À LIRE !

• Evolutionary Architecture And Emergent design, Neal Ford. IBM Developer Works.

http://www.ibm.com/developerworks/views/java/libraryview.jsp?site_id=1&contentarea_by=Java&sort_by=Date&sort_order=1&start=1&end=19&topic_by=&product_by=&type_by=All%20Types&show_abstract=true&search_by=evolutionary%20architecture%20emergent%20design:&industry_by=&series_title_by=