SlideShare une entreprise Scribd logo
OOP
&
DESIGN PATTERN
Tarik Zakaria Benmerar
Acigna Inc.
OOP and Design Patterns
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 ];
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: ----------------------------------------------------------------------
<?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;
});
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:
<?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();
}
}
?>
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 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();
}
}
?>
LE DESIGN PATTERN
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).
Extracted vs. preemptive frameworks
The 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 :
OOP and Design Patterns
QUELQUES CLASSIQUES À
LIRE !
• Evolutionary Architecture And Emergent design, Neal Ford.
IBM Developer Works.
http://www.ibm.com/developerworks/views/java/libraryview.js
p?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%20ar
chitecture%20emergent%20design:&industry_by=&series_titl
e_by=

Contenu connexe

Similaire à OOP and Design Patterns

Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
Tarik Zakaria Benmerar
 
DesignPatternsISI.pdf
DesignPatternsISI.pdfDesignPatternsISI.pdf
DesignPatternsISI.pdf
andre543581
 
Design patterns - Exemples en Java
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en Java
Oussama BEN KHIROUN
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
ECAM Brussels Engineering School
 
Sql azure performance et montee en charge (1)
Sql azure   performance et montee en charge (1)Sql azure   performance et montee en charge (1)
Sql azure performance et montee en charge (1)
Aymeric Weinbach
 
Jpa(1)
Jpa(1)Jpa(1)
Jpa(1)
Assad Lion
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
linasafaa
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
cyrilgandon
 
Drupal7 - Bonnes Pratiques (Partie 1)
Drupal7 - Bonnes Pratiques (Partie 1)Drupal7 - Bonnes Pratiques (Partie 1)
Drupal7 - Bonnes Pratiques (Partie 1)
Alexandre Marie
 
SQL Server et les développeurs
SQL Server et les développeurs SQL Server et les développeurs
SQL Server et les développeurs
Microsoft
 
Cours dao
Cours daoCours dao
Cours dao
AlassaneKabr
 
Cours jdbc
Cours jdbcCours jdbc
Cours jdbc
AlassaneKabr
 
Javascript proprement
Javascript proprementJavascript proprement
Javascript proprement
Guillaume Collic
 
Azure Camp 9 Décembre - slides session développeurs webmedia
Azure Camp 9 Décembre - slides session développeurs webmediaAzure Camp 9 Décembre - slides session développeurs webmedia
Azure Camp 9 Décembre - slides session développeurs webmedia
Microsoft
 
Formation d'architecte logiciel AFCEPF
Formation d'architecte logiciel AFCEPFFormation d'architecte logiciel AFCEPF
Formation d'architecte logiciel AFCEPF
Boubker ABERWAG
 
Rails 3 au Djangocong
Rails 3 au DjangocongRails 3 au Djangocong
Rails 3 au Djangocong
Jérémy Lecour
 
La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !
La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !
La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !
Paris Salesforce Developer Group
 
Seance_1_cours_introduction_java_Copie.pptx
Seance_1_cours_introduction_java_Copie.pptxSeance_1_cours_introduction_java_Copie.pptx
Seance_1_cours_introduction_java_Copie.pptx
RihabBENLAMINE
 
Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022
Laurent Guérin
 
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017) Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
univalence
 

Similaire à OOP and Design Patterns (20)

Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
 
DesignPatternsISI.pdf
DesignPatternsISI.pdfDesignPatternsISI.pdf
DesignPatternsISI.pdf
 
Design patterns - Exemples en Java
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en Java
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
 
Sql azure performance et montee en charge (1)
Sql azure   performance et montee en charge (1)Sql azure   performance et montee en charge (1)
Sql azure performance et montee en charge (1)
 
Jpa(1)
Jpa(1)Jpa(1)
Jpa(1)
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
 
Drupal7 - Bonnes Pratiques (Partie 1)
Drupal7 - Bonnes Pratiques (Partie 1)Drupal7 - Bonnes Pratiques (Partie 1)
Drupal7 - Bonnes Pratiques (Partie 1)
 
SQL Server et les développeurs
SQL Server et les développeurs SQL Server et les développeurs
SQL Server et les développeurs
 
Cours dao
Cours daoCours dao
Cours dao
 
Cours jdbc
Cours jdbcCours jdbc
Cours jdbc
 
Javascript proprement
Javascript proprementJavascript proprement
Javascript proprement
 
Azure Camp 9 Décembre - slides session développeurs webmedia
Azure Camp 9 Décembre - slides session développeurs webmediaAzure Camp 9 Décembre - slides session développeurs webmedia
Azure Camp 9 Décembre - slides session développeurs webmedia
 
Formation d'architecte logiciel AFCEPF
Formation d'architecte logiciel AFCEPFFormation d'architecte logiciel AFCEPF
Formation d'architecte logiciel AFCEPF
 
Rails 3 au Djangocong
Rails 3 au DjangocongRails 3 au Djangocong
Rails 3 au Djangocong
 
La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !
La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !
La Tooling API, est-ce pour moi ? Bien sûr, viens voir pourquoi !
 
Seance_1_cours_introduction_java_Copie.pptx
Seance_1_cours_introduction_java_Copie.pptxSeance_1_cours_introduction_java_Copie.pptx
Seance_1_cours_introduction_java_Copie.pptx
 
Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022
 
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017) Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
 

Plus de Algiers Tech Meetup

Introduction to aws
Introduction to awsIntroduction to aws
Introduction to aws
Algiers Tech Meetup
 
Data tracking using Google Analytics
Data tracking using Google AnalyticsData tracking using Google Analytics
Data tracking using Google Analytics
Algiers Tech Meetup
 
Introducing Firebase by Google
Introducing Firebase by GoogleIntroducing Firebase by Google
Introducing Firebase by Google
Algiers Tech Meetup
 
Presentation of Oracle database products
Presentation of Oracle database productsPresentation of Oracle database products
Presentation of Oracle database products
Algiers Tech Meetup
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
Algiers Tech Meetup
 
Rex Agility at icosnet
Rex Agility at icosnetRex Agility at icosnet
Rex Agility at icosnet
Algiers Tech Meetup
 
Introduction to Arduino
Introduction to ArduinoIntroduction to Arduino
Introduction to Arduino
Algiers Tech Meetup
 
Overview of Telecommunication networks
Overview of Telecommunication networksOverview of Telecommunication networks
Overview of Telecommunication networks
Algiers Tech Meetup
 
Material Design for Android
Material Design for AndroidMaterial Design for Android
Material Design for Android
Algiers Tech Meetup
 
The future of JavaScript
The future of JavaScriptThe future of JavaScript
The future of JavaScript
Algiers Tech Meetup
 
Security of Hosting Platforms
Security of Hosting PlatformsSecurity of Hosting Platforms
Security of Hosting Platforms
Algiers Tech Meetup
 
Agile Spirit
Agile SpiritAgile Spirit
Agile Spirit
Algiers Tech Meetup
 

Plus de Algiers Tech Meetup (12)

Introduction to aws
Introduction to awsIntroduction to aws
Introduction to aws
 
Data tracking using Google Analytics
Data tracking using Google AnalyticsData tracking using Google Analytics
Data tracking using Google Analytics
 
Introducing Firebase by Google
Introducing Firebase by GoogleIntroducing Firebase by Google
Introducing Firebase by Google
 
Presentation of Oracle database products
Presentation of Oracle database productsPresentation of Oracle database products
Presentation of Oracle database products
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
 
Rex Agility at icosnet
Rex Agility at icosnetRex Agility at icosnet
Rex Agility at icosnet
 
Introduction to Arduino
Introduction to ArduinoIntroduction to Arduino
Introduction to Arduino
 
Overview of Telecommunication networks
Overview of Telecommunication networksOverview of Telecommunication networks
Overview of Telecommunication networks
 
Material Design for Android
Material Design for AndroidMaterial Design for Android
Material Design for Android
 
The future of JavaScript
The future of JavaScriptThe future of JavaScript
The future of JavaScript
 
Security of Hosting Platforms
Security of Hosting PlatformsSecurity of Hosting Platforms
Security of Hosting Platforms
 
Agile Spirit
Agile SpiritAgile Spirit
Agile Spirit
 

OOP and Design Patterns

  • 1. OOP & DESIGN PATTERN Tarik Zakaria Benmerar Acigna Inc.
  • 3. LES PRINCIPES DE LA CONCEPTION DES LOGICIELS
  • 4. DRY ( DON’T REPEAT YOURSELF ) Chaque connaissance dans le système doit avoir une représentation unique et non ambigüe.
  • 5. DRY: • Réutilisez du code, ne le dupliquez pas. • Choisissez des noms clairs. • Choisissez le bon endroit pour le code.
  • 6. 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(); ?>
  • 7. 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
  • 8. SRP ( SINGLE RESPONSABILITY PRINCIPLE ) Chaque code doit avoir une seule responsabilité. Le code doit être cohésive.
  • 9. 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"; } } ?>
  • 10. TDA ( TELL DON’T ASK ) Déclarez des actions, au lieu de se poser des questions.
  • 11. 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; });
  • 12. YAGNI ( YOU AREN’T GONNA NEED IT YET ) Ecrivez du code que vous avez besoin maintenant.
  • 13. OCP ( OPEN CLOSE PRINCIPLE ) Ouvert pour l’extensibilité. Fermé pour la modification.
  • 14. LSP ( LISKOV’S SUBTITUTION PRINCIPLE ) Utilisez l’héritage seulement si vous signifiez la substitution des deux classes (parent et fils).
  • 15. 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(); } } ?>
  • 16. DIP ( DEPENDENCY INVERSION PRINCIPLE ) Inversement du contrôle des dépendances.
  • 17. 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(); } } ?>
  • 19. 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.
  • 21. 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.
  • 22. 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.
  • 23. 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).
  • 24. 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.
  • 25. 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.
  • 26. TOUT CELA EST BIEN, MAIS CE N’EST QUE LE DÉBUT DE L’HISTOIRE……
  • 27. LE DESIGN EMERGEANT (ET ARCHITECTURE ÉVOLUTIONNAIRE)
  • 28. 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.
  • 29. 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).
  • 30. Extracted vs. preemptive frameworks The 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.
  • 31. LE PATTERN DU DOMAINE (ANALYSIS PATTERN)
  • 32. • 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 :
  • 33. MODÈLE DE COMPTABILITÉ AVEC UN SYSTÈME DE TRANSACTION
  • 35. • 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 :
  • 38. • Evolutionary Architecture And Emergent design, Neal Ford. IBM Developer Works. http://www.ibm.com/developerworks/views/java/libraryview.js p?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%20ar chitecture%20emergent%20design:&industry_by=&series_titl e_by=