design-patterns-java-1222499509564319-8

*Design Patterns JAVAConception dapplications objetB.Vinot

*Contenu du cours Introduction aux DP Principes fondamentaux de conception Les patterns GRASS Ouverture-Fermeture (OCP) Inversion des dpendances (DIP) Substitution de Liskov (LSP) Sparation des interfaces (ISP) Mthodes de DVP et Processus Up XP Tests et Refactoring Les design patterns Les DP du GOF (23) Comportement (11) Structure (7) Cration (5) Autres Patterns Les Patterns d'analyse Le Raii Organisation MVC Les frameworks Les composants Les packages Mtriques

*Pourquoi faire de l'objet(1) ?

Graph1

17

11

8

17

14

11

7

6

2

2

5

Feuil1

Increased Productivity17

Cost savings11

Improved interfaces8

Software reuse17

Improved application maintenance14

Encapsulate existing applications11

Develop strategic applications quickly7

Develop applications as revenue source6

Access new OS and tools2

Explore ability to develop OO2

Other5

100

Feuil1

Feuil2

Feuil3

*Pourquoi faire de l'objet(2) ?

C++

C++

C++

C

C

C

V0

V1

V2

V0

V1

V2

Average Function LOC

6,66

6,2

6,11

29,62

32,5

37,11

Min Function LOC

2

1

1

3

3

3

Avg Cyclomatic Complex

1,66

1,59

1,59

5,88

6,25

6,56

Avg Comparison Complex

0,25

0,24

0,3

1,38

1,62

2,22

Avg Logic Flow Complex

1,91

1,83

1,89

7,25

7,88

8,78

Avg Function Complexity

3,69

3,59

3,7

9

9,62

10,56

eLoc/100

2,07

2,5

2,68

2,68

2,91

3,53

eLOC

207

250

268

268

291

353

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java *

The Alternative: Allow Iteration

Escher was the first:-)

C++

C++

C++

C

C

C

V0

V1

V2

V0

V1

V2

Average Function LOC

6,66

6,2

6,11

29,62

32,5

37,11

Min Function LOC

2

1

1

3

3

3

Avg Cyclomatic Complex

1,66

1,59

1,59

5,88

6,25

6,56

Avg Comparison Complex

0,25

0,24

0,3

1,38

1,62

2,22

Avg Logic Flow Complex

1,91

1,83

1,89

7,25

7,88

8,78

Avg Function Complexity

3,69

3,59

3,7

9

9,62

10,56

eLoc/100

2,07

2,5

2,68

2,68

2,91

3,53

eLOC

207

250

268

268

291

353

*Introduction aux Design PatternsLes Patterns GRASSGeneral ResponsabilityAssignement Software Patterns

*Les Patterns : IntroductionNaissance des patterns : Les patterns furent utiliss bien avant que les systmes dinformations modernes napparaissent, dans dautres disciplines comme la construction et larchitecture de btiments. 1987, Beck et Cunningham dfinissent des patterns pour interfaces utilisateurs.1994 : Design Patterns : Elements of reusable object oriented software Gof pour Gang of Four (Gamma, Helm, Johnson et Vlissides)

Craig Larman dcrit des modles de conception plus intuitifs : les Patterns GRASP : General Responsability Assignement Software Patterns, ou patterns gnraux daffectation des responsabilits.

*Les Patterns : DfinitionUn design pattern est un modle de conception. Au fur et mesure des dveloppements, des principes gnraux rptitifs sont remarqus, et des solutions courantes sont identifies. En formalisant celles-ci, sous la forme de la prsentation dun problme de conception, et de la solution pour le rsoudre, on obtient un design Pattern. Un design pattern doit rpondre certains aspects essentiels : Un pattern a un nom vocateur, qui reprsente bien lessence mme de son existence. Exemple : le pattern GoF Singleton Un pattern rsout un problme. Exemple : une classe ne peut avoir quune et une seule instance disponible. Un pattern fourni une solution-gnie (voir le pattern singleton plus loin) Un pattern doit tre expliqu (documentation-uml)

*Exemple : Les Patterns GraspCest presque du bon sens Lexpert (affectation des responsabilits) Le crateur Faible couplage Forte cohsion Contrleur

*Le pattern GRASP : ExpertQui fait quoi : le modle Expert est un pattern relativement intuitif, qui en gnral, est respect par le bon sens du concepteur. Il sagit tout simplement daffecter une classe les responsabilits correspondants aux informations dont elle dispose intrinsquement (quelle possde) ou non ( objets de collaborations ).on ne peut exiger dun rfrigrateur quil fasse radiateur et range-disquesDonner des dfinitions (c'est trs difficile)int i; // variable i entire

*Le pattern GRASP : CrateurQui cre qui? : Ce pattern consiste en la dtermination de la responsabilit de la cration dune instance dune classe par une autre. Une classe A agrge des instances de la classe B Une classe A contient des instances de la classe B Une classe A utilise des instances dune classe B Une classe A possde les donnes ncessaires linitialisation des instance de classe B, etc. Variables globales! Notion de configurateurDlguer la fabrication qq dautre! Persistance (JDBC,DAO)

*Le pattern GRASP : Couplage Le couplage exprime la relation troite quun lment (Classe, Systme ou sous systme) entretien avec un ou des autres lments. Un lment faiblement coupl ne possde pas ou peu de dpendances vis a vis dautres lments. Les objets sont coupls (paresseux)Un objet qui est connu de personne est inutile.Un objet qui connat personne ne fait pas grand chose (sauf Utility)Parler des classes abstraites plus tt qu des classes concrtes

*Le pattern GRASP : CohsionEsprit de famille La cohsion mesure le degr de spcialisation des responsabilits dun composant / classe. La cohsion mdiocre altre la comprhension, la rutilisation, la maintenabilit et subit toute sorte de changements. Exception pour Corba, RMI, ..(pb de granularit)

*Le pattern GRASP : ContrleurLe contrleur contrle. Il est entre la vue et les entits (MVC)Une classe Contrleur doit tre cre si elle rpond lun des cas suivants

La classe reprsente une contrleur de faade, cest dire linterface daccs lensemble dun systme. La classe reprsente le scnario dun cas dutilisation. On le nomme en gnral Session , et est charg de traiter tous les vnements systmes contenus dans un scnario de cas dutilisation.Un contrleur contient : Ce qui ne concerne pas la vue Ce qui ne concerne pas les entits (Expert)

*Principes fondamentaux de conceptionOuverture-Fermeture OCPInversion des dpendances DIPSubstitution de Liskov LSP Sparation des interfaces ISP

*Les objectifs du DESIGNviter les phnomnes de dgnrescence de l'applicationDu point de vue du design, trois risques principaux pnalisent les activits de dveloppement :La rigidit : chaque volution est susceptible d'impacter de nombreuses parties de l'application Extensibilit.

La fragilit : la modification d'une partie de l'application peut provoquer des erreurs Robustesse

L'immobilit : il est difficile d'extraire une partie de l'application pour la rutiliser dans une autre application. Rutilisation

*Gestion des volutions et des dpendances entre classesPrincipe douverture/fermeture Open-Closed Principle (OCP) Touche pas mon codePrincipe de substitution de Liskov Liskov Substitution Principle (LSP) Les enfants doivent respecter le contratPrincipe dinversion des dpendances Dependency Inversion Principle (DIP) Utiliser des InterfacesPrincipe de sparation des interfaces Interface Segregation Principle (ISP) Diviser les interfaces

*Exemple : utilisation de la dlgation abstraite (OCP)A gre les cas c1 et c2. Si un nouveau cas c3 doit tre gr, il faut modifier le code de A en consquence :

*Lapplication de lOCP est un choix stratgique (OCP)L'OCP est un principe incontournable lorsque l'on parle de flexibilit du code. Par contre, une erreur classique consisterait vouloir ouvrir/fermer toutes les classes de l'application en vue d'ventuels changements. Cela constitue une erreur dans la mesure o la mise en oeuvre de l'OCP impose une certaine complexit qui devient nfaste si la flexibilit recherche n'est pas rellement exploite.Il convient donc d'identifier correctement les points d'ouverture/fermeture de l'application, en s'inspirant :des besoins d'volutivit exprims par le client,des besoins de flexibilit pressentis par les dveloppeurs,des changements rpts constats au cours du dveloppement.La mise en oeuvre de ce principe reste donc une affaire de bon sens.

*Exemple : (OCP)Personnenom : stringage : intPersonne(n : string, a : int)Appl1Appl2BDAppl3Avec adr Rajouter un attribut Rajouter un constructeur Rajoute un paramtre au constructeur Faire une nouvelle classe PersonneAdr Rajouter une mthode getAdr mme ds Personne

*Exemple : (OCP) SolutionAppl1Appl2Personnenom : stringage : intPersonne(n : string, a : int)GetAdresse() : stringPersonneDomicileeadresse : stringPersonneDomiciliee(n : string, a : int, adr : string)GetAdresse() : stringSetAdresse(p : string) : voidRend une chane vide:Appl3 peut alors utiliser des PersonnesJouer sur les mthodes plus tt que sur les attributsLes gains : 2 versions dans le mme excutable pas besoin de faire de VNR (faites la quand mme)

*Principes de substitution de LISkOV (LSP)Pour prtendre l'hritage, une sous-classe doit tre conue de sorte que ses instances puissent se substituer des instances de la classe de base partout o cette classe de base est utilise.Hriter dune interfaceEn insistant sur cette approche de l'hritage, le principe de substitution s'oppose une pratique rpandue dans laquelle l'hritage est mis en oeuvre pour factoriser du code entre plusieurs classes.

*Principes de substitution de LISkOV (LSP) : exempleclass Rectangle { int longueur, largeur; public: virtual void setValeur(int long, int larg) {longueur = long; largeur = larg; };class Carre : public Rectangle { public: virtual void setValeur(int long, int larg) { if (long != larg) throw std::exception(long !=larg"); super.setValeur(long, larg); } }; void utiliserRectangle(int lng) { leRectangle.setValeur(lng, lng * 2); assert(leRectangle.getArea() == (length*length*2));Que se passe-t-il si le Rectangle est un carr?HritageComposition

*Principes dinversion des dpendances (DIP)Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "mtier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :" Le passage l'abstrait est valoris"

*Principes dinversion des dpendances (DIP)Cela parat naturel au premier abord mais pose en ralit deux problmes essentiels :Les modules de haut niveau doivent tre modifis lorsque les modules de bas niveau sont modifis.Il n'est pas possible de rutiliser les modules de haut niveau indpendamment de ceux de bas niveau. En d'autres termes, il n'est pas possible de rutiliser la logique d'une application en dehors du contexte technique dans lequel elle a t dveloppe.La relation de dpendance doit tre inverse : les modules de bas niveau doivent se conformer des interfaces dfinies et utilises par les modules de haut niveau.

*Labstraction comme technique dinversion des dpendances (DIP)Considrons deux classes A et B, A utilisant B comme indiqu sur le schma ci-dessous :

Pour inverser la dpendance de A vers B, on introduit une classe d'interface I dont drive B comme suit :

*Principes de sparation des interfaces (ISP)Pollution d'interface par agrgation de servicesOn retrouve dans la plupart des designs quelques classes qui rendent plusieurs services simultanment, comme l'illustre le schma ci-dessous :

*Principes de sparation des interfaces (ISP)L'inconvnient de ce genre de cas est que tous les clients ont une visibilit sur tous les services rendus par la classe :Chaque client voit une interface trop riche dont une partie ne l'intresse pas,Chaque client peut tre impact par des changements d'une interface qu'il n'utilise pas.

Solution : sparation des services de l'interfaceLe principe de sparation des interfaces stipule que chaque client ne doit "voir" que les services qu'il utilise rellement

*Principes de sparation des interfaces (ISP)

*Techniques de sparation (ISP)Il existe deux techniques principales de mise en pratique de l'ISP :L'hritage multiple,Le Design Pattern "Adapter".

*Sparation par hritage multiple (ISP)Dans cette approche chaque service est reprsent par une classe d'interface dont drive la classe qui implmente les services. Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schma suivant :

*Sparation par adaptateur (ISP)Lorsque l'hritage multiple n'est pas possible, les services peuvent tre reprsents par des classes d'adaptation :

*Processus ObjetUPXP-AgileWinston Royce. Managing the Development of Large Software Systems. 1970

*UP: Caractristiques essentielles Caractristiques essentielles du processus unifi :- Le processus unifi est base de composants,Le processus unifi utilise le langage UML (ensemble d'outils et de diagramme),- Le processus unifi est pilot par les cas dutilisation,Centr sur larchitecture (plate-forme, performances, rutilisation, indpendantedes UC, Y, )- Itratif et incrmental.UPRUPXUP

*UP & les modles UML (1)

*UP & les modles UML (2)

Modle des cas dutilisation Expose les cas dutilisation et leurs relations avec les utilisateursModle danalyseDtaille les cas dutilisation et procde unepremire rpartition du comportement du systme entre divers objetsModle de conceptionDfinit la structure statique du systme sousforme de sous systme, classes et interfaces ;Dfinit les cas dutilisation raliss sous forme de collaborations entre les sous systmes les classes et les interfacesModle dimplmentationIntgre les composants (code source) et lacorrespondance entre les classes et les composantsModle de testDcrit les cas de test vrifiant les cas dutilisationModle de dploiementDfinit les nuds physiques des ordinateurs etlaffectation de ces composants sur ces nuds.Modle d'architectureDescription de larchitecture (rutilisable)

*UP & L'organisation matricielle

*Processus ObjetXP-AgileExtrem programingLa programmation extrmeLes processus agiles

*Pourquoi une nouvelle Mthode ?

Les approches classiques de dveloppement type "waterfall", bases sur la fameuse Squence spcification / conception / ralisation / validation, souffrent de problmes chroniques : Les spcifications sont dfinies au dbut du projet, alors qu'on en sait encore peu sur le sujet, Les spcifications diffrencient rarement ce qui est important de ce qui ne l'est pas, L'application se rigidifie progressivement en un produit "final" souvent difficile faire voluer et maintenir, Les activits sont compartimentes en fonction des spcialits des dveloppeurs, ce qui pose des problmes de rpartition des tches et limite la circulation des connaissances dans l'quipe.

*Les mthodes agiles Anne 80 : RAD (100 jours) Anne 90 : XP (Chrysler) et DSDM (Angleterre) (Dynamic Software Development Method) 2001 : Le manifeste Agile individus et interactions plutt que processus et outils dveloppement logiciel plutt que documentation exhaustive collaboration avec le client plutt que ngociation contractuelle ouverture au changement plutt que suivi dun plan rigide

*Les valeurs d' XP (1) Communication XP intgre rellement le client au projet pour qu'il dfinisse mieux ses besoins, arbitre les priorits et apporte ses connaissances mtier l'quipe.XP fait travailler tous les dveloppeurs ensemble et les fait participer toutes les activits du dveloppement, crant ainsi une relle dynamique d'quipe.XP rend accessible tous les intervenants l'ensemble des indicateurs d'avancement du projet.FeedbackXP fournit des livraisons rgulires au client pour lui permettre d'affiner et de complter la dfinition de ses besoins partir de donnes concrtes.XP met en place des batteries de tests d'acceptation qui mesurent concrtement l'avancement des dveloppements.XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui dtectent instantanment toute rgression.

*Les valeurs d' XP (2)SimplicitXP s'assure que seules les fonctionnalits demandes par le client sont implmentes.XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et conserver une grande vitesse de dveloppement tout au long du projet.CourageXP donne au jour le jour une transparence maximale sur l'tat d'avancement rel du projet.XP s'attaque aux problmes ds qu'ils se prsentent, en autorisant des retours en arrire s'ils sont ncessaires.

*Binme (1)BinmeBien peru des programmeursGarantit lhomognit du code, le respect des rgle de codageResponsabilit et connaissance collective du codeFacilite la communication (moins de situation de blocage)Pousse bien faire (Motivation et satisfaction) Phase d'adaptation de 2 semaines Ne pas accepter ceux qui refusent Le code est de meilleur qualit (ils pensent + aux cas particuliers)Stand up meeting chaque soirFaire tourner les binmesRpartition des comptences

*Binme (2)Exploration dun problme (Spike - CrcCards)Nom des objets (bonne comprhension)Prendre le temps de bien le faire (Mtaphore local)Documenter le codePas de documentation mais un code bien comment (Dclaration)Espace de travailEspace de dveloppement centralBureautique en priphrieGrande table de runion dans le bureauGrand crans pour le dveloppementTout le monde se voit (mobilier spcifique?)

*TUTests unitairesAide la conception dtaillSystmatiquement avant le code (inhabituelle)Ne doit pas passer au dbut (Iconoclaste?) Ne pas dvelopper plus que ce qui est ncessaire pour le testAuto-vrifiant (18000 tests passs en 15 mn-tests passs de 15 mn 20 secondes)Tous les tests de tous les modules doivent passer sans erreur avant dintgrer le codeSuper aide la non rgression, au changement de conception et au remaniement Cela peut tre mis en uvre hors de XP

*La PlanificationLa planification collective en dbut dincrment (Une journe)Incrment de trois semainesLecture et explications des user stories (cas dutilisation) Grandes lignes de la conceptionDfinition et valuation des tchesvaluation en temps idal + Load factorvaluation en deux groupes. Le minimum est choisi si aucune difficult na t oublie.

*Conditions dapplicationIl faut : Une quipe qui sentende bien et rduite (12 max) Dveloppement mono site Programmation par composants Que le client participe et adhre

Il ne faut pas: Une spcification complte et dtaille du futur systme Mesurer la qualit de la documentation au poids

*Les principes de base Seul le code source fait foi, il possde une odeur Limportant cest le programmeur Faire le plus simple possible Restructurer ds que ncessaire Pratiquer la programmation par paire Les spcifications sont des histoires dutilisateurs La planification est un jeu Livrer frquemment Tester encore, toujours et tout le temps tre courageux

*histoires dutilisateurs Des descriptions rdiges par les utilisateurs (clients) Pour chaque histoire : le client donne : Priorit Tests dacceptation Les dveloppeurs : Estimation de la charge de la ralisation (lhistoire peut tre dcoupe en tches)Une histoire est une unit de livraisonRMQ : Une histoire est un trs gros use case

*La planification est un jeuXP tente de dsamorcer les conflitsUn vrai dialogue

*tre courageux Standup meeting Choisir des tches que lon ne sait pas faire Accepter dexpliquer aux autres ce que lon sait Sarrter de dvelopper pour faire du refactoring Accepter de ne pas tre responsable, alors quon est plus fort Ne pas avoir les yeux plus gros que le ventre

*DroulementScrum

*Processus ObjetTestsRefactoring

*Test et Junit

*Junit

*Junit : Ecrire le testpackage com.moi.test.junit; import junit.framework.TestCase; public class MaClasseTest extends TestCase { private MaClasse maClasse = null; public MaClasseTest(String arg0) { super(arg0); } public static void main(String[] args) { junit.swingui.TestRunner.run(MaClasseTest.class); } protected void setUp() throws Exception { super.setUp(); maClasse = new MaClasse(); } protected void tearDown() throws Exception { super.tearDown(); maClasse = null; } public void testAdditioner() { assertTrue(maClasse.additioner(2,2) == 4); } }

*Junit : lancement du testRegrouper les tests :Sur un projet ou un packageFaire new JunitTestSuite(Other)Junit4

*Tests : Les couchesBlablaObjetsmtierCTRLBDSerialisation Les objets mtier offrent des interfaces pour les IHM (le CTRL) En analyse : Les trois axes d' une classeStringglobal

*Couverture de test

*Le Refactoring :Principes (1)Programmer au plus simpleFaire du refactoring tout le temps (comme le mnage)Faire des itrations spcialesSassurer que :Les tests existentIls sont OKFaire des petites chosesRenommerDcouperDplacer

*Le Refactoring :Principes (2)Mettre en place des design patternsComposer des design patternsAccepter de" refactorer " le code des autresRemonter des interfacesUtiliser des Interfaces ou des classes abstraitesUtiliser les outils de refactoring (Eclipse)

*Le refactoring dans Eclipse (1)Extract Method : Cre une nouvelle mthode encapsulant les lments slectionns, et remplace toutes les rfrences ces lments (mme ailleurs dans le code), par un appel vers cette mthode.Rename : Renomme l'lment slectionn.Move : Dplace l'lment slectionn, par exemple enlever la classe du paquetage actuel, et la place dans un autre paquetage (voire un nouveau)Change Method Signature : Modifie la signature de la mthode en cours, c'est--dire ses droits d'accs (public / private / protected / default). Peuvent galement tre modifis par cet assistant : le type du rsultat, l'ordre, le nom et le type des paramtres et les dclarations d'exceptions. Convert Local Variable to Field : Transforme une variable locale, dfinie dans une mthode, en champ de classe

*Le refactoring dans Eclipse (2)Extract Local Variable : De la mme manire que Extract Method, cette fonction cre une nouvelle variable assigne l'expression slectionne.

Inline : C'est la fonction inverse de Extract Local Variable : elle rtablit l'expression assigne la variable, en lieu et place de la variable, qui disparat. Particulirement utile si l'on se rend compte qu'une variable locale n'est utilise qu'une fois, et que le programme n'est jamais assez optimis.Push Down... Pull Up : Ces deux fonctions marchent dans le mme sens, mais avec des directions diffrentes : elles dplacent la slection respectivement vers la sous-classe ou la superclasse actuelleUse Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifi auparavant tous les emplacements o ce remplacement est possible.

*Le refactoring dans Eclipse (3)Extract Interface : l'instar des prcdentes fonctions de types Extract, celle-ci se charge de prendre les lments slectionnes et d'en tirer une classe disposant des mthodes de la classe en cours, et implmente cette interface sur la classe.Encapsulate Field : Remplace toutes les rfrences un champ de classe, par des mthodes get et set pour ce champ.Introduce Factory : Cre une nouvelle mthode de type Factory (voir plus loin), en gnrant pour un constructeur donn la mthode statique approprie.

*Le refactoring dans Eclipse (4)Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifi auparavant tous les emplacements o ce remplacement est possible. .

*Refactoring : exercice(1)Un film une catgorie (enf, norm, nouv) un titre

Une location concerne un film une dure

Cot de la location norm : 2 + 1.5 par jour au de la du deuxime jour nouv : 3 par jour enf : 1.5 + 1.5 par jour au de la du troisime jourBonus : Chaque location donne un point, si une nouveaut est loue plusqu'un jour, alors un point supplmentaire.

*Refactoring : exercice(2)

*Refactoring : exercice(3)

*Refactoring : correction

*Les Design patternsLe GoFComportementStructureCration

*Les Design Patterns Problme: Comment allouer des objets en mmoire ? Contexte: un grand nombre dobjets allous en mmoire virtuelle. Solution: identifier les objets amens collaborer frquemment un certain moment (ralisation dun service), et allouer ces objets dans une mme page mmoire.Alexander writes:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. Le choix des Design Patterns et de leur codage est un choix darchitectureLes outils permettent dinstancier les Design Patterns et de gnrer automatiquement le code

*Prsentation des patrons de conceptionLe patron de conception est lexpression dune problmatique rcurrente dun domaine et la dfinition dune solution gnrique ce problme.Le concept nest pas spcifique linformatique puisque son domaine dorigine est larchitecture.Les patrons de conception introduisent la rutilisation des expriences de conception logicielleLes problmes abords nous sont souvent familiers et les solutions proposes peuvent paratre simposer, mais cest lutilisation effective et au quotidien de ces prceptes qui constitue le vritable dfit et apporte une vritable plus-value.

*

Description des patrons de conceptionUn patron de conception est une description textuelle, ventuellement enrichie de modles UML, dun problme de conception et du cur de sa solution.Cette description comporte typiquement les lments suivants :Un nom permettant de lidentifierLe problme et son contexteLes lments de solution et leurs relationsLes bnfices et consquences induitsLe catalogue le plus connu est celui de Erich Gamma qui recense dans son livre quelques 23 modles de conception oriente objet

*Classification des patterns

Cration

Comportement

Structure

*Les Design patterns de comportement (1) State : un objet ragit selon son humeur Stratgie : Faire une chose de diffrentes manires Template Methode : Faire une chose de diffrentes manires (avec une recette de base) Observer : certains sont intresses par ce que je fais, mais pas tout le temps Visiteur : Rajouter une responsabilit une classe avec des sous traitements identiques Memento : sauvegarder un objet Iterateur : Balayer une collection Chane de responsabilit : un lment est attendu par un grand nombre d'objets

*Les Design patterns de comportement (2) Commande : encapsule une requte dans un objet, et permet les files d'attentes, les journalisassions , et retours en arrire (undo). Mdiateur : dfinit un objet qui encapsule la manire dont un ensemble d'objets interagissent. Interprteur : dfinit un langage ainsi que sa grammaire, et fournit un interprteur pour utiliser la reprsentation du langage.

*lAutomate : contexteProblme : Un mme objet doit rpondre une mme sollicitation de plusieurs manires diffrentes suivant son tat interne. Les oprations produisent des rsultats qui dpendent de ltat interne.Contexte : Fournir un approche systmatique dimplantation des diagrammes dtats UML Solution : On va dissocier ltat de lobjet de lobjet lui-mme. Les tats seront matrialiss par autant de classes, chacune spcialise dans la gestion dun de ces tats. Lobjet na plus qu grer une instance reprsentant ltat courant et dlgue les appels de mthodes cette instance. Une classe parente abstraite ou une interface commune permettra lobjet de les manipuler dune faon homogne.

*State : PrambuleSoit des stagiaires qui ragissent selon leur humeur : Si on leur demande de travailler: Si cest le matin, ils coutent. Si cest laprs midi, ils font la sieste. Si cest midi juste, ils grognent Si on leur demande de faire un exercice .

*State : UML

*State : ParticipantsLes classes et/ou objets participant dans ce pattern sont:Context Dfint la classe principale utilise par le client Garde une instance de la sous classe state pour dfinir ltat courant. Etat Dfinit linterface des diffrents tats.Concrete State Chaque sous classe implmente linterface du State conformment ce qui est faisable dans cet tat.

*State : Exercice1- La banqueSilverState(0-1000)do: Interet = 10%RedState(1000)do: Interet = 50%[ balance > 1000 ][ balance < 0 ][ balance > 0 ][ balance < 1000 ][ balance < 0 ]

*State : Exercice1- La banquebalance Interet 0%Balance entre 0 et 1000 => Interet 10%Balance > 1000 => Interet 50%balance Pnalit de 15

*State : Exercice1int main(){Account account("Jim"); account.Deposit(500.0); account.PayInterest (); account.Deposit(300.0);account.PayInterest (); account.Deposit(550.0); account.PayInterest(); account.Withdraw(2000.00);account.PayInterest(); account.Withdraw(1100.00) ;account.Withdraw(1000);account.PayInterest();account.Deposit(2000);return 0;}GoldSilverrSilverRed Silver

*State + Singleton

*State + SingletonExo2Objet o;o.C1();o.C2();o.C3();o.C3();Objet o1;o1.C1();o1.C3();o1.C2();o1.C1();o1.C2();o1.C3();o1.C1();o1.C3();

*State : RemarquesRemarques :Les tats concrets peuvent possder une rfrence lobjet (possibilit pour ltat concret de manipuler les attributs de lobjet) Le changement dtat peut tre grer par lobjet lui-mme ou par les tats concrets.

Consquences :De nouveaux tats peuvent tre facilement ajoutsLes transitions dtat sont plus explicitesSi les tats concrets nont pas dtats internes (variables), alors ils peuvent tre partags (singleton)

Plus simple

*Stratgie : contexteOn utilise Stratgie lorsque : De nombreuses classes associes ne diffrent que par leur comportement. Ce pattern permet de configurer une classe avec un comportement parmi plusieurs. On a besoin de plusieurs variantes d'algorithme. Un algorithme utilise des donnes que les clients ne doivent pas connatre.

*Stratgie : UML

*Stratgie : ParticipantsLes classes et/ou objets participant dans ce pattern sont:Strategie(SortStrategy) Dclare une interface commune pour tous les algorithmes supports.ConcreteStrategie(QuickSort, ShellSort, MergeSort) Implmente un algorithme conformment linterface de la Strategie.Context(SortedList) Est configur avec un objet concreteStrategy Maintient une rfrence sur un objet Strategy Peut dfinir une interface qui permet la stratgie daccder ses donnes.

*Stratgie : ExoRenvoyer Celui qui gagne le plus Celui qui prend le plus de vacances Celui qui public static void main(String[] args) {Entreprise e= new Entreprise();Employe trouve;e.Ajouter(new Employe ("Tchutchu" , 999999 , 0));e.Ajouter(new Employe ("Duchmoll" , 1000 , 10));e.Ajouter(new Employe ("Casta" , 10000 , 30));e.setMaStrategie(new RechercherGrossesVacances());trouve = e.Rechercher();System.out.println ("Virer le paresseux : " + trouve.getNom());e.setMaStrategie(new RechercherGrosSalaire());trouve = e.Rechercher();System.out.println ("Virer le plus cher : " + trouve.getNom());}Virer le paresseux : CastaVirer le plus cher : Tchutchu

*Patron de mthode : principe Cest du code (un algorithme cabl pour toutes les sous classes) qui est fait principalement par appel de mthodes virtuelles et abstraites. Ressemble un template C++ Mcanismes trs diffrents Plus souple Les traitements peuvent diverger dune sous classe lautre alors que cela est impossible avec les templates Plus simple Cest du code en avance sur les futures sous-classes Avantage : Dcoupe des mthodes en mthodes plus fines

*Patron de mthode : ExempleTravaillerMatin();Dejeuner();TravaillerApresMidi();Loisir();Dormir();Patron de mthodevivreIf (age > 15)TravaillerMatin();else Jouer();.MiamMiamRonRonCest drle

*Patron de mthodeBlaBlater:BlaBlaTravaillerMatin: BlaBlater();TravaillerApresMidi: BlaBlater();Loisir: BlaBlater

*Patron de mthodeTravaillerMatin();Dejeuner();TravaillerApresMidi();Loisir();Dormir();TravaillerMatin:Dormir();TravaillerApresMidi:AllerANPE();Loisir:Pleurer();

*Patron de mthode : Exo : ImptsNouvelle loi de finance : Impts sur le revenu : Couple avec enfants : Frais : -20 % moins 1000 par enfant IR = reste * 2/12 Couple sans enfant : Frais : -20 % IR = reste * 3/12 ClibataireFrais : -10 % IR = reste * 4/12 Taxe dhabitationCouple avec enfants : Un loyer moins 50 par enfants Couple sans enfant : Deux loyers Clibataire Deux loyers + 1000 ISFCouple avec enfants : 20% de (ISF-300000) si > 300000 sinon 0 Couple sans enfant : 20% de (ISF-200000) si > 200000 sinon 0 Clibataire 20% de (ISF-80000) si > 100000 sinon 0 Tout le monde profite dun parachute (non golden) qui slve au max 50% des revenus. Un clibataire libral paye un surplus dimpt de 5000 indpendamment du parachute fiscal TVA sociale augmente de 5 points

(Calcul sur le revenu annuel)Dclaration : Revenu annuel-loyer mensuel-fortune-nombre denfants

*Patron de mthode : Exo : Impts

*lObserver : le contexteProblme : Dfinir une interdpendance de type (de classe) un plusieurs, de faon telle que, quand un objet change d'tat, tous ceux qui en dpendent en soit notifis pour assumer leur propre mise jour.Contexte : Ne pas prsumer de lidentit des objets intresss par lvnement (limitation du couplage). Ne pas prsumer du nombre des intresssSolution : Implantation dune interaction entre objets de type souscription-diffusion

*lObserver : la solutionle Sujet : Dfinit un mcanisme gnral de gestion des objets en dpendanceMaintient la liste des Observeurs laide des mthodes attach(Observer*) et detach(Observer *)Fournit le mcanisme permettant de prvenir les Observeurs lorsquun changement dtat se produitlObserveur : Dfinit linterface update() permettant dtre prvenu dun changement dtatle SujetConcret : Sous-classe de Sujet, gre son tat interne et invoque notify() lorsque son tat changeles Observeurs Concrets : Sous-Classes dObserveur, implentent linterface update() en fonction de leur besoin

*lObserver : UMLRutilisableRmq : souvent UpDate contient des paramtres (evt, le sujet, l'tat du sujet, )

*lObserver : la dynamique

*Observer : Participants Les classes et/ou objets participant dans ce pattern sont: Sujet(Stock) Connat les observateurs. Plusieurs observateurs peuvent observer un mme sujet. Cela peut tre dynamique. Offre un moyen dattacher et de dtacher les observateurs. SujetConcret(IBM) Cest lui qui contient linformation observable. Prvient les observateurs quand linformation change. Observer(IInvestor) Cest juste la dfinition de linterface. les Observeri(Investor) Garde une rfrence sur le Sujet concret implmente linterface de lobserver pour aller chercher linformation.

*Observer : JavasetChanged () {changed = true;}NotifyObservers() {if (changed) {for each observer update();changed = false;}Cela permet d'optimiser enn'appelant pas les observers chaque changement d'tat dusujet,mais seulement aprs unsetChanged().import java.util.*;

*Observer : Java- SwingPublic class Exemple{JFrame cadre;

Public static main(){Exemple e = new Exemple();e.go();}Public void go(){cadre =new JFrame(); Jbutton b = new Jbutton (Dois-je le faire);b.AddActionListener(new Ange());b.AddActionListener(new Demon());.}}class Ange implements ActionListener {Public void ActionPerformed(ActionEvent e) {Print Non}}

class Ange implements ActionListener {Public void ActionPerformed(ActionEvent e) {Print Oui}}Dois-je le faireNonOui

*Observer : Exercice1Meteo.Calculer met temprature entre 0 et 20.Skieur.update va en vacances si la temprature est < 10 Nageur.update va en vacances si la temprature est >= 10Meteo m = new Meteo();Nageur n = new Nageur();Skieur s =new Skieur();m.addObserver(n);m.addObserver(s);m.calculer();m.setChanged();m.calculer();m.setChanged();m.calculer();m.setChanged();m.calculer();le skieur va a la montagne : 8le nageur va a la mer : 12le skieur va a la montagne : 68812?

*Observer : Exercice2

*Visitor Rajouter une (ou plusieurs) mthode un objet (sans la rajouter) !!!! A utiliser quand une classe ne sait pas ce quelle veut et quelle risque de vouloir beaucoup de choses. La classe fait dj beaucoup de petites choses L'objet visit accepte le visiteur (Accept (Visitor v)) Il dit alors v de visiter (v.Visit()) v fait son travail

*Visitor : UML

*Visiteur et lobjet CompositeIterator iter =employees.iterator();{ Employee e;while (iter.hasNext()) { e =(Employee)iter.next(); e.Accept(visitor);}}RMQ : Il est possible dexplorer lensemble dun composite avec un visiteur.Dans ce cas Employee et Employees ont tous les deux une mthode Accept etsont donc des Elements.

*Visitor :exercicepublic static void main(String[] args) {Employees e = new Employees(); e.Attach(new Clerk("Hank", 25000.0, 14)); e.Attach(new Director("Elly", 35000.0, 16)); e.Attach(new President("Sarko", 45000.0, 21)); e.Accept(new IncomeVisitor()); e.Accept(new VacationVisitor()); }Une entreprise veut soit : augmenter les salaires de 10% donner 2 jours de vacances supplmentaires d'autres combinaisons TBD

*Visitor :correction

*Mmento : UMLLa classe surveiller-----La mmoire----Le programme client (main)

*Mmento : Participants

Memento Stock ltat interne (tout ou partie) de lobjet Origine. Il se protge contre les accs provenant dautres objets que lOriginator. Les mementos ont en effet 2 interfaces. Le careTaker voit une interface simplifie, il peut seulement passer le memento dautres objets. Au contraire loriginator voit une large interface, qui lui permet daccder a tous les champs.Originator Cre un memento contenant une photo de lui mme un instant donn (sauvegarde). Utilise le memento en cas de restauration.Caretaker Est responsable de la gestion des sauvegardes-restauration Il ne regarde jamais le contenu interne du Memento

*Mmento : Exemple(1)import java.util.*;

// "Originator"

class SalesProspect{ private String name; private String phone; private double budget;

public String getName() { return name; } public void setName(String value) { name = value; } public String getPhone() { return phone; } public void setPhone (String value) { phone = value; } public double getBudget() { return budget; } public void setBudget (double value) { budget = value; }

public Memento SaveMemento() {return (new Memento( name, phone, budget ));}

public void RestoreMemento( Memento memento ) { this.name = memento.getName(); this.phone = memento.getPhone(); this.budget = memento.getBudget(); }

public void Afficher() { System.out.println( "Sales prospect ---- " ); System.out.println( "Name: " + this.name ); System.out.println( "Phone: " + this.phone ); System.out.println( "Budget:" + this.budget ); }}class Memento{ private String name; private String phone; private double budget;

// Constructors public Memento( String name, String phone, double budget ) { this.name = name; this.phone = phone; this.budget = budget; }

public String getName() { return name; } public void setName(String value) { name = value; } public String getPhone() { return phone; } public void setPhone (String value) { phone = value; } public double getBudget() { return budget; } public void setBudget (double value) { budget = value; }}// "Caretaker"class ProspectMemory{ private Memento memento; public void setMemento (Memento value){ memento = value; } public Memento getMemento () { return memento; }}

*Mmento : Exemple(2)public class MementoApp{ public static void main(String argv[]) { SalesProspect s = new SalesProspect(); s.setName ( "Landru"); s.setPhone ("08080808"); s.setBudget( 25000.0); s.Afficher();

// Store internal state ProspectMemory m = new ProspectMemory(); m.setMemento( s.SaveMemento());

// Continue changing originator s.setName( "Tintin"); s.setPhone( "33333333"); s.setBudget( 1.0); s.Afficher();

// Restore saved state s.RestoreMemento( m.getMemento() ); s.Afficher();

}}

*Memento : UML-Dynamique : Client : Caretaker : Originator : Memento

SaveMemento(): void

SetState(): voidrend le mementoSetMemento(p Memento): voidGetMemento(): voidRestoreMemento(m): voidGetState(): voidmis a jour de l'tat()

*LItrateur-Iterator : le contexteBalayer des collections

Problme, pas d'iterateur pour les tableaux, mais on peutle dvelopper

*Itrateur: UML

*Iterateur : ParticipantsLes classes et/ou objets participant dans ce pattern sont:Iterator dfinit une interface pour accder et traverser les lments dune collection.ConcreteIterator(Iterator) implmente linterface Iterator. garde trace de la position courante dans la collection.Aggregate(AbstractCollection) dfinit une interface pour crer (obtenir) un objet Iterator.ConcreteAggregate(Collection) Implmente linterface de cration et rend une instance dun objet ConcreteIterator

*Itrateur : remarquesUn itrateur est dit robuste, sil garantit que insertions et suppressions ninterfreront pas avec le parcours.Problme MultithreadDes oprations supplmentaires peuvent tre utilises : SauteA, PrcdentUne classe ne doit avoir qu'une seule responsabilit (au sens large) sinon, il y a plus de risques de changementJava 5 (generics)For (Object o : Collection){ o.fqq();}

*Itrateur & Composite Itrateur interneOn peut balayer un composite en utilisant l'opration prvue (exempleGetCout()). Partir de la racine et simplement appeler la mthode Itrateur externeIl faut l'crireMise en uvre d'une pileUtiliser des iterator normaux pour les lments composs

*Itrateur : ExerciceReprendre l'ordinateur du Composite Mettre les diffrents lments dans des tableaux Faire un iterateur de tableau Faire un itrateur externe pour l'ensemble

*Chane de Responsabilit Polymorphisme et rcursivit Utiliser la pattern Chane de responsabilit quand vous voulez donner plus dun objet une chance de traiter une requte Lensemble des objets est construit dynamiquement

Avantages : Dcouple lmetteur de la requte de ses rcepteurs Simplifie lobjet qui envoie la requte car, il na pas besoin de connatre la structure de la hirarchie utilise, ni de conserver des rfrences directes sur les membres. Permet dajouter, modifier , supprimer des responsabilits en changeant la hirarchie

Exemples : Machine trier les pices

Traitement des mails lettres de fan => PDG rclamations => Service juridique demandes de modification => R&D publicit => Poubelle

*Chain of Resp : UMLDeux temps : Configurer la hirarchie Faire des demandes

*Chain of Resp : Participants Les classes et/ou objets participant dans ce pattern sont: Handler (Approver) dfinit une interface pour grer les requtes (optionnel) implmente le lien successeur ConcreteHandler (Director, VicePresident, President) Gre une requte si il en est responsable Peut accder son successeurPasse la requte son successeur si il ne peut pas la traiterClient (ChainApp) Provoque le premier appel de la requte vers un ConcreteHandler de la chane des successeurs.

*Chain of Resp : ExoPrsident

*Command Faire faire qq chose un objet sans le connatre Commander qq chose sans connatre celui qui le fera Rduction du couplage Permet : les logs (historiques) les undo-redo (avec ou sans Memento) temporisation d'action mise en file d'attente contrle souvent utiliser avec un composite pour excuter plusieurs commandes (notion de macro commande)

*Command : UMLConfigurateurUtilisateur

*Command : Participants Les classes et/ou objets participant dans ce pattern sont: Command dfinit une interface pour faire faire qq chose (Execute) ConcreteCommand Connat celui qui fait qq chose (Receiver) Implmente la mthode Execute en faisant faire le travail aureceiver. Receiver Fait le travail, il ne connat personne Client Connat la ou les commandes concrtes et les initialisent avec un receiver. Invoker Fait faire qq chose sans connatre ni les commandes concrtes ni les receivers (seulement l'interface)

*Command : Exo Un architecte (client) Chef de chantier(Invoker) Pltrier(Receiver) Maon(Receiver) Couvreur (Receiver) Couvreur vreux (Receiver) Faire les murs externes (Action) Faire les murs internes (Action) Faire le toit (Action) Faire des recettes (DeAction) Construire (Command)Je construis les murs extJe construis le toitJe casse le toitJe construis le toitJe casse le toitJe construis le toitJe construis les murs int

*Command : CorrectionJe construis les mursJe construis le toitJe casse le toitJe construis le toitJe casse le toitJe construis le toitJe construis les murs

*Interpreter : UML

*Mediator : UMLMediatorConcreteMediatorColleague+mediatorboutonlistetextAreaControleurmenuRmq :Faade-Observer

*Les Design patternsLe GoFStructure Proxy : cacher la complexit d'un objet Dcorateur : Rajouter une responsabilit une classe sans changer l'interface Adaptateur : Adapter un objet un autre Composite : permet de traiter une structure d'objets de manire uniforme (Des feuilles et des nuds) Faade : Reprsenter, regrouper et diriger un ensemble d'objets Poids mouche : Partager de nombreux minis objets Pont : permet de diffrencier une abstraction de son implmentation, permettant chacune d'voluer indpendamment.

*Proxy :le contexteOn utilise un proxy : pour rfrencer un objet par un moyen plus complexe qu'un "pointeur". pour rajouter, modifier, supprimer des responsabilits un objet sans en changer ni la structure interne, ni l'interface.

Il existe plusieurs types de proxy : Proxy distant (RMI) Proxy virtuel pour le cas de chargement d'objet trs volumineux Proxy de protection Proxy de rfrence intelligente : Persistence Comptage de rfrence .

*Proxy : UMLProxy.Operation1() {fait qqchose..leSujet.Operation1();}

Proxy.Proxy(Sujet param){leSujet = param;}

*Proxy : Participants Les classes et/ou objets participant dans ce pattern sont: Proxy remplace lobjet rel et pointe vers celui-ci Operation1 fait le traitement suivant:Proxy distant : fabrique un message et l'envoie au Sujet rel viaun skeleton. Le proxy s'appelle alors un stub. Proxy de protection : vrifie si l'appelant a les droits pour excuterl'opration, il l'accepte ou la refuse.On peut utiliser l'API InvocationHandler Proxy virtuel : exemple chargement d'une image. Le proxy lancele chargement de l'image et affiche le % de temps restant. Lorsque l'image est charge, alors il l'affiche.Proxy de rfrence intelligente : exemple smart pointer du C++Sujet Dfinit linterface commune au proxy et au sujet rel. SujetReel Dfinit lobjet rel que le proxy reprsente.

*Proxy DistantRPCRMICORBADCOMWEBSERVICEStubskeletonIDLInterfaceWSDL

*Proxy Distant :RMI (1)Utilisation de rmi ( import java.rmi.* ) Crer une interface distante: public interface Sujet extends Remote public void Operation1() throws RemoteException; s'assurer que les paramtres et valeur de retour sont serialisable Crer une implmentation distante SujetReel public class SujetReel extends UnicastRemoteObject implements Sujet Ecrire un constructeur sans argument,avec excptpublic SujetReel() throws RemoteException vv Enregistrer le servicetry {SujetReel leSujetReel = new SujetReel();naming.rebind ( "BonjourDeLoin" , leSujetReel); }catch (Exception e) {}

*Proxy Distant :RMI (2) Gnrer le stub (proxy) et le skeleton lancer rmic sur le fichier SujetReel.java rmic SujetReel Excuter rmiregistry (outil pour l'enregistrement) en tapant simplement dans une fentre dos rmiregistry Dmarrer le service en tapant : java SujetReel

Le client peut alors utiliser le service Sujet monSujet = (Sujet) Naming.Lookup("rmi://127.0.0.1/ BonjourDeLoin");monSujeT.Operation1();Proxy Distant :Exercice

*Proxy de protection :exercice (1)

*Proxy de protection :exercice (2)

*Proxy de protection avec InvocationHandlerMoi mmeLes autresgetNom()getSexe()getInterest()getSexyOuNon()SetNom(String)setSexe(String)setInterest(String)setSexyOuNon(int)Rmq : setSexyOuNon () fait la moyenne des notes obtenuesgetNom()getSexe()getInterest()getSexyOuNon()SetNom(String)setSexe(String)setInterest(String)setSexyOuNon(int)

*Proxy de protection avec InvocationHandler

*Mthode invoke de non PropritaireInvocationHandlerNonProprietaire

public Object invoke(Object proxy, Method method, Object[] args)throws IllegalAccessException { try {if (method.getName().startsWith("get")) {return method.invoke(personne, args); } else if (method.getName().equals("setSexyOuNon")) {return method.invoke(personne, args);} else if (method.getName().startsWith("set")) {throw new IllegalAccessException();} } catch (InvocationTargetException e) { e.printStackTrace();}return null;}

*Mthode invoke de PropritaireInvocationHandlerProprietaire

public Object invoke(Object proxy, Method method, Object[] args)throws IllegalAccessException { try {if (method.getName().startsWith("get")) {return method.invoke(personne, args); }else if (method.getName().equals("setSexyOuNon")) {throw new IllegalAccessException();}else if (method.getName().startsWith("set")) {return method.invoke(personne, args);} } catch (InvocationTargetException e) {e.printStackTrace();} return null;}

*Proxy invocationHandler :Exercice(1)Rmq basedonnees est une Hashtable----------------------------------------------Passage difficile :

*Proxy invocationHandler :Exercice(2)

*Decorator : PrsentationProblme : nombreux hritages

Solution : Hritage hritage + agrgation (poupe russe)

*Decorator :Le problme(1)Nous allons revoir la faon dont on abuse gnralement de lhritage et vous allez apprendre comment dcorer vos classes aumoment de lexcution en utilisant une forme de composition.Pourquoi? Une fois que vous connatrez les techniques de dcoration, vous pourrez affecter vos objets (ou ceux des autres) denouvelles responsabilits sans modifier le code des classes sous-jacentes. RMQ :Le principe dOuverture (nhsitez pas tendre nos classes) et de Fermeture (Pas touche mon code)Un Deca avec du lait et du citron

*Decorator :Le problme(2)Ecrire les mthodes Boisson::Cout etColombia::CoutBoisson.Cout(){If GetLait() then cout += coutDuLaitIf GetVanille() then cout += coutVanille.Return cout;}

Colombia::Cout (){Return 25+ super.Cout()}Que se passe-t-il si on rajoute la crme Chantilly?Il faut modifier Boisson.Cout --- Pas touche mon code

*Decorator : UMLDecorateuri.Operation():fait qq chosesuper.Operation()Cela revient rajouter une responsabilit une classe mais sans en changer l'interface.Comparer avec le compositeComposantConcret.Operation : fin de la chaneDecorateur.Operation() :monComposant.Operation()

*Decorator : la solution constructionDecaLaitCitronLa boissonLes ingrdientsFabrication de l'objet : Boisson b= new Deca(); b = new Lait(b); b = new Citron (b); b = new Citron(new Lait(new Deca()));Un Deca avec du lait et du citronDe l'extrieure, on ne voitque le citron.

*Decorator : la solutionUn Deca avec du lait et du citronDecaLaitCitronLa boissonLes ingrdientsCalcul du cot de la boisson : citron = 0.2(Fait qq chose) +super.Operation monComposant.Operation lait = 0.3 (Fait qq chose) +super.Operation monComposant.Operation Deca = 0.5

Au retour Total = 1

*Decorator : ParticipantsLes classes et/ou objets participant dans ce pattern sont:Component (Boisson) Dfinit linterface pour les objets qui peuvent avoir des responsabilits ajoutes dynamiquement. ConcreteComponent (deca) Dfinit un objet auquel on peut rajouter des responsabilits.Decorator (Ingredient) Maintient une rfrence sur le component et dfinie une interface conforme conforme celle du component.ConcreteDecorator (citron) Ajoute les responsabilits au composant.

*Decorator : ExempleOn utilise lhritage entre Ingrdient et boisson par SnobismeBoisson::Cout est abstraiteColombia::Cout return 25 (le cot du Colombia sans ingrdientLait::Cout return le cout du Lait(10) + Le cot de maBoissonUtilisation :Boisson b1 = new Colombia()b1.cout() => 25

Boisson b2 =new Colombia()b2 = new Lait(b2);b2.cout()=> 25 + 10

b2 = new Citron(b2); ..ColombiaQue se passe-t-il si on rajoute la crme Chantilly?Il faut rajouter la classe Chantilly

*Decorator : Un mauvais exemple(1)

*Decorator : un mauvais exemple (2)

*Decorator : Exercice

*lAdaptateur : le contexteObjectif :L'adaptateur met en conformit l'interface d'une classe au besoin d'une classe cliente. L'adaptateur permet des classes de collaborer, qui n'auraient pu le faire du fait d'interfaces incompatible.Contexte : Ce pattern est particulirement adapt lorsque les conditions suivantes sont remplies :On veut utiliser une classe existante dont l'interface ne concide pas avec celle escompteOn souhaite crer une classe qui puisse tre accde par des interfaces diversesRcupration de vieilleriesFaade

*lAdaptateur : Uml et Exemple

*L'adaptateur : ParticipantsLes classes et/ou objets participant dans ce pattern sont: Cible Dfinit ce qui est appel par le client Adapteur Fait le lien entre ce que veut le client et ce qui existe vraimentAdapt Cest ce qui existe vraiment (rcupration) Client Ne connat que linterface de la cible.

*L'adaptateur : ExerciceCanard.Cancaner "Coincoin"Leurre.Cancaner "Silence"CanardPlastique "Pchiff"Oie.Cacarder " CoincoinCoincoin "

Pb : Faire cancaner une troupe de Cancaneur contenant des oies

*Composite : Le contexte & UMLOn utilise le Composite lorsque on veut : Reprsenter une hirarchie d'objets Ignorer la diffrence entre un composant simple et un composanten contenant d'autres (interface uniforme) Comparer avec le dcorateur

*Composite : Participants

Component (Equipement) Dclare linterface pour les objets de la composition. Leaf (Peripherique) Reprsente les objets feuilles (sans enfants) de la composition. Dfinit le comportement de ces objets.Composite (Container) Dfinit le comportement des objets ayant des enfants. Range, stocke les composants enfants Client(pg main) Manipule les objets comme un seul en sappuyant sur linterface du component.

Utilisation : Fabriquer l'objet (Configurer) Le client peut alors appeler Operation () sur l'objet global. L'objet global est un composite (ou une feuille) particulier qui prmet de retrouverl'ensemble du composite

*Composite : Exercice// ConfigurationPeripherique p1 = new Peripherique ("DVD", 100,8);Peripherique p2 = new Peripherique ("Disque Dur", 1000,9);Peripherique p3 = new Peripherique ("Modem ADSL", 1,8);Peripherique p4 = new Peripherique ("Pentium", 3500 ,386);Peripherique p5 = new Peripherique ("Ventilo ", 150,15);Container carteMere = new Container ("Carte mre");carteMere.Ajouter(p4);carteMere.Ajouter(p5);TourDeLuxe tour = new TourDeLuxe ("tour",100);tour.Ajouter(p1);tour.Ajouter(p2);tour.Ajouter(carteMere);Container ordi = new Container ("IBM");Ordi.Ajouter (tour);ordi.Ajouter (p3);// UtilisationSystem.out.println( "le prix total est de : " + ordi.GetPrix() );CompositeLeaf

*Composite : Solution

*Faade : UML

*La Faade : le contexteProblme : La conception objet implique la dcomposition de chaque systme complexe en collection dobjets collaborant.On veut limiter le couplage des utilisateurs du systme avec les lments de cette dcomposition.On veut garder la possibilit pour certains client de manipuler lintrieur du systme.

Solution : On cr un nouvel objet servant de faade un type dutilisateur donn et lui offrant des services de haut niveau.

*La Faade : les bnficesConsquences :Dcouplage dune partie des clients avec le systme considr. Rduction du nombre de classes (complexit) prendre en compte pour ce client Rduction des dpendances la compilation

Certains langages (C++ avec les NameSpaces, java avec les packages) permettent de cacher une partie des classes dun sous-systme.-> Encapsulation au niveau des systmes

*Faade : ParticipantsLes classes et/ou objets participant dans ce pattern sont: Faade (Prt) Connat les classes du sous systme qui sont responsables dechaque requte.Transmet les requtes aux classes adquat.Subsystem classes (VerifApport, VerifSalaire, VerifCaution) Implmentent les fonctionnalits du sous systme. Ne connaissent pas la faade Exemple : Transformation d'une liste en pile

*Faade : Exo Apport est au moins de 10% du prt Prt = 50% du prtFacade f =new Facade();System.out.println(f.AccepterPret(100000,1000,20000,55000));System.out.println(f.AccepterPret(200000,1000,20000,55000));System.out.println(f.AccepterPret(300000,1000,20000,55000));trueRefus caution trop faiblefalseRefus salaire trop faibleRefus caution trop faibleRefus apport trop faiblefalsePrt, salaire, apport, caution

*Flyweight : Poids mouche :UMLUtilisation : beaucoup de petits objets se partager plusieurs.Exemple :les caractres d'un document PluriGleton

*Poids mouche : Exemple : une fort Avantages : Rduit le nb d'instances Economise la mmoire Rmq :tous les arbres doiventtre grs de la mme manire

*Bridge : UMLRmq : ressemble au state

*Bridge : Exemple#include using namespace std;

// .hclass Implementor;class Abstraction { protected :Implementor *implementor; public : void SetImplementor(Implementor *value); virtual void Operation();} ; class Implementor { public : virtual void Operation()=0; } ; class RefinedAbstraction : public Abstraction { public :void Operation();}; class ConcreteImplementorA : public Implementor { public : void Operation() ; } ; class ConcreteImplementorB : public Implementor { public : void Operation() ;};

// .cpp void Abstraction::SetImplementor(Implementor *value) {implementor = value;} void Abstraction::Operation() { implementor->Operation(); } void RefinedAbstraction::Operation(){ implementor->Operation(); } void ConcreteImplementorA::Operation(){cout Operation(); }

*Les Design patternsLe GoFCration Singleton : un et un seul objet visible par tous Fabrication : crer un objet en fonction d'un paramtre Fabrique abstraite : crer une famille d'objets tous cohrents Monteur : construire un objet en diffrentes tapes Prototype : permet de spcifier le type d'objets crer en utilisant une instance prototype. Le prototype sera copi pour crer les nouveaux objets.

*Problme : Une classe ncessite de ntre instancie quune seule fois dans une applicationContexte : Cette instance unique est utilisable plusieurs endroits dans lapplication.Solution : On va confier la classe elle-mme la responsabilit dassurer lunicit de son instance.Le singleton

*Le singleton uml

*Amlioration du singleton L'usine singleton : Remplacer singletons par singleton

Rmq : En C++, mettre en private le constructeur de copie et l'oprateur d'affectation

Rmq : En multi thread, utiliser un mutex ou synchronized.

*Fabrication : PrsentationLe problme :If cas1 alors return new c1();If cas2 alors return new c2();If cas3 alors return new c3();Problme de dpendance, ce sous programme dpend de c1,c2,c3.Et ce problme arrive chaque fois que l'on veut crer un des ces objets.C'est du code Beurgh!

La fabrication va garder et prendre en charge ce code Beurgh, au moinsIl sera un seul endroit.Rgle POO :Remplacer le switch par le polymorphismeFabrication :Garder le switch ce qui vitera de faire des New (et des dpendances)

*Fabrication : Problme de dpendance La fabrication va permettre l'inversion des dpendances on va encapsuler la cration des objets dans une fabrique on peut crer plusieurs objets, mais ils sont indpendants les unsdes autres

*Fabrication : exemple les pizzerias(1)L'usineLes produits

*Fabrication : exemple les pizzerias(2) : qqcelleDeBrest : Pizzeriabrest-fromage : PizzacommanderPizza(type: String): pizzacreerPizza(item: String): pizzapreparer(): voidcuire(): voidcouper(): voidemballer(): void[B]Pizza creerPizza(String item) if (item.equals("fromage")) { return new PizzaFromageStyleBrest();} else ifPizzeria fabriqueBrest = new FabriqueDePizzasBrest(); [A] Pizza pizza = fabriqueBrest.commanderPizza( "fromage" );[B]System.out.println("Luc a command une " + pizza.getNom() + "\n");[A]

*Fabrication : le Design pattern

*Fabrication : Participants Les classes et/ou objets participant dans ce pattern sont: Produit(Page) Dfinie linterface des objets crs par la fabrication (Afficher) ProduitConcreti(Introduction,Plan,Conclusion,Dev) implementent linterface du produit (CreatePages) Createur(Document) Dclare la mthode "Fabrication(String) : Produit" qui rend un objet de type Produit. CreateurConcret(Report, Resume) Surcharge la mthode Fabrication pour rendre une instance du produit concret. C'est le code Beurgh!!! Rmq :la mthode peut ne pas avoir de paramtre, dans ce cas le code n'est pas beurgh.

*Fabrication exerciceFabriqueLe produitFabriquePage fab = new FabriquePage();Page i = fab.CreatePage("Intro");i.Afficher();i=fab.CreatePage("Conclusion");i.Afficher();

*Fabrication Abstraite : motivationApplicationIHMMotifIHMwindowsApplicationIHMIHMMotifIHMwindowsLapplication utilise IHM sans savoir si ilsagit de Motif ou bien de Windows

*Fabrication Abstraite : Structure

*Fabrication Abstraite : Constituants FabriqueAbstraite (Facultative) Dclare une interface contenant les oprations de cration dobjets produits abstraits Fabrique concrte Implmente les oprations de cration dobjets produits concrets Produit Abstrait (Facultatif) Dclare une interface pour un type dobjet produit Produit concret Dfinit un objet produit qui doit tre cre par la fabrication concrte correspondante Implmente linterface de ProduitAbstrait Application nutilise que les interfaces dclares par les classes FabriqueAbstraite etProduitAbstrait

*Fabrique Abstraite : Avantages et inconvnients Isoler les classes concrtes Faciliter la substitution dune famille de produits Favoriser le maintien de la cohrence entre les objets Grer de nouveaux types de produits est complexe Ne facilite pas la lisibilit

*Builder-MonteurRmq : Le monteur (Builder) est utilis pour construire diffrentes sortes dobjets selon une certaine mthodologie (tapes par tapes). Chaque tape dpend du type de lobjet, mais la succession des tapes en est indpendante. (comparer avec le patron de mthode)On utilise le buider lorsque : L'algorithme pour crer un objet doit tre indpendant des parties quile composent et de la faon de les assembler. Le processus de construction permet diffrentes reprsentations del'objet construit.

*Builder : UML

*Builder : ParticipantsLes classes et/ou objets participant dans ce pattern sont:Builder(VehicleBuilder) Spcifie une interface pour identifier les tapes de la cration dun produit.ConcreteBuilder(MotorCycleBuilder, CarBuilder, ScooterBuilder) Construit et assemble les diffrentes parties dun objet en implmentant linterface du Builder. Dfinit le produit final et permet de le retrouver.Director(Shop) Cest le client (celui qui utilise le builder).Product(Vehicle) Reprsente le ou les produits fabriqus

*Builder : Exemplevoici la partie A du produit1voici la partie B du produit1voici la partie A du produit2voici la partie B du produit2

*Builder : Exo void main() { Shop shop = new Shop(); VehicleBuilder b2 = new CarBuilder(); VehicleBuilder b3 = new MotorCycleBuilder(); shop.Construct(b2); b2.GetVehicle().Show(); shop.Construct(b3); b3.GetVehicle().Show(); }

*Prototype Masque au client les complexits de la cration de nouvelles instances (new, clone, deserialisation, ) Permet au client de gnrer des objets dont le type nest pas connu. Dans certaines circonstances, la copie dun objet peut tre plus efficace que la cration dun objet (memberWiseClone du c#)

*Prototype : ParticipantsLes classes et/ou objets participant dans ce pattern sont:Prototype Dclare une interface pour se clonerConcretePrototype Implmente une opration pour se clonerClient Cr un nouvel objet en demandant au prototype de se cloner.

*DP : Exercice gnral(1)Les stagiaires ont un nom, un sexe et une catgorie (TM, M, Moyen, B , TB). Ils font des exos qui sont russis en fonction de leur tat (TM =4-10, M=5-10, B=10-15, TB=15-20,Moyen =11)Le prof note alatoirement (presque) les exos mais favorise les filles. (note en fonction de ltat, plus ou moins un nombre compris entre 10 et + 8, rajouter 2 points pour les filles (sauf pour les trs bonnes), la note finale est comprise entre 0-20. Quand un lve obtient une note < 7 son tat se dgrade, alors que si il obtient une note > 13 son tat samliore. Le chef vire celui ou celle qui a la plus mauvaise note chaque exercice.Bill Gates dbauche 2 fois le ou la meilleure, tandis que Google nen dbauche quun ou quune.Dautres personnes, entreprises ou organismes quelconques pourront bientt s intresser aux stagiaires.Toutes les notes sont sauvegardes pour chaque lve.SingletonStateObserverStrategieTemplate methodememento

*DP : Exercice gnral(1)

*DP : Exercice gnral(2) Traiter le cas des oies Compter les coinscoins Comment tre sr de compter tout le monde ? Faire cancaner toute une troupe Observer de temps en temps et en temps rel le couac de chaque canardAdaptateurDecorateurFabrique abstraiteCompositeObserver

*Autres PatternsLes classes d'analyseLe raii

*Les classes d'analyse Les trois axes d'une classe : Boundery - Frontire - Vue Contrleur Entity - Objets mtier - modlea2uc2uc3a3protocole

*RAII : Prsentation du pbTout sest mal pass et en plusOn ne libre pas les ressources

*(RAII) la sauce Java (Finally)

*RAII la sauce C++Selon l'approche RAII, on peut modifier la classe Datafile pour qu'elle fasse le Open() dans son constructeur (avec leve d'exception), et le Close() dans son destructeur. Puis l'on cre une petite classe utilitaire DBLock qui gre le verrouillage de la base :

*Patterns et architectureMVCFrameWorkOrganisation des packagesMtriques

*Vue12345(Origine :SmallTalk-Xerox) L'utilisateur a fait qq chose (bouton, menu, .)Le contrleur prvient le modleModification d'IHM (bouton non disponible, menu gris, )Le modle prvient la vue que qq chose est arriv (changement d'tat Notify)La vue demande des informations complmentairesCela permet d'avoir plusieurs vues, plusieurs modlesMVC

*CompositeStratgie/etatSujetObserverUpDate()MVC : Design pattern compos

*Framework : IntroductionDfinition : Un framework est une infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothques de classes ou de gnrateurs de programmes, soit dit en quelques mots : un cadre de dveloppement.

Exemples:Struts est un framework java d'interfaage homme machine pour applications web.SWING est un framework java d'interfaage homme machine pour une application fentre. Les MFC sont un framework C++ d'interfaage d'une application avec le systme d'exploitation windows. la GTK est un framework C d'interfaage homme machine avec une application fentre, conu l'origine pour les systmes unix et port sur windows. java est un framework, Dot.net aussi, Junit est un framework de test .

*Framework : UtilisationIl existe des frameworks de divers types, et ceux-ci sont complmentaires un framework runit l'ensemble des implmentations rcurrentes de nos dveloppements. Les avantages en sont : viter de recoder encore et toujours les mmes bouts de codes rbarbatifs, agir en un point unique pour modifier l'ensemble du comportement applicatif (Par exemple le "look and feel") faisant profiter toutes les applications des avances du framework, assurer la robustesse de ces parties du code (rptitives et essentielles).

Exemple Spring : Java JEE est trop compliqu(pas d'hritage et de polymorphisme avecLes EJB. Struts pour la prsentation Hibernate pour la persistance

*ComposantUn composant est form avec: Une interface dfinissant la structure objet ncessaire la ralisation d'un travail (ou plusieurs) son implmentation.

Runir un ensemble des classes et des interfaces ayant des comportements agissant dans le mme sens au sein de composants. Les divers composants communiquent par le biais d'une Faade.

*Organisation des packages

*Dpendances cycliques : InterfaceL'application : Cre un objet A Cre un objet B Prsente B A en tantque FqqAble Prsente A B en tantque FqqAble

*Mtriques (1) Lines of Code (LOC): Le nombre total de lignes de code. Les lignes blanches et les commentaires ne sont pas comptabiliss Number of Static Methods (NSM): Le nombre de mthodes statiques dans l'lment slectionn. Afferent Coupling (CA): Le nombre de classes hors d'une package qui dpendent d'une classe dans le package Normalized Distance (RMD): RMA + RMI - 1: Ce nombre devrait tre petit, proche de zro pour indiquer une bonne conception des parquets. Number of Classes (NOC): Le nombre de classes dans l'lment slectionn. Specialization Index (SIX): NORM * DIT / NOM: Moyenne de l'index de spcialisation. Instability (RMI): CE / (CA + CE) : Ce nombre vous donnera l'instabilit de votre projet.C'est--dire les dpendances entre les paquets. Number of Attributes (NOF): Le nombre de variables dans l'lment slectionn. Number of Packages (NOP): Le nombre de packages dans l'lment slectionn. Method Lines of Code (MLOC): Le nombre total de lignes de codes dans les mthodes. Les lignes blanches et les commentaires ne sont pas comptabiliss Weighted Methods per Class (WMC): La somme de la complexit cyclomatique de McCabe pour toutes les mthodes de la classe. Number of Overridden Methods (NORM): Le nombre de mthodes redfinies. Number of Static Attributes (NSF): Le nombre de variables statique. Nested Block Depth (NBD): La profondeur du code

*Mtriques (2) Number of Methods (NOM): Le nombre de mthodes . Lack of Cohesion of Methods (LCOM): Une mesure de la cohsion d'une classe. Plus le nombre est petit et plus la classe est cohrente, un nombre proche de un indique que la classe pourrait tre dcoupe en sous-classe. Nanmoins, dans le cas de Javabean, cette mtrique n'est pas trs correcte, car les getteurs et les settteurs sont utiliss comme seules mthodes d'accs aux attributs. Le rsultat est calcul avec la mthode d' Henderson-Sellers : on prend m(A), le nombre de mthodes accdant un attribut A, on calcule la moyenne de m(A) pour tous les attributs, on soustrait le nombre de mthodes m et on divise par (1-m). McCabe Cyclomatic Complexity (VG): La complexit cyclomatique d'une mthode. C'est--dire le nombre de chemins possibles l'intrieur d'une mthode, le nombre de chemin est incrment par chaque boucle, condition, oprateur ternaire, # Il ne faut pas que ce nombre soit trop grand pour ne pas compliquer les tests et la comprhensibilit de la mthode. Number of Parameters (PAR): Le nombre de paramtres. Abstractness (RMA): Le nombre de classes abstraites et d'interfaces diviss par le nombre total de classes dans un package. Cela vous donne donc le pourcentage de classes abstraites par package Number of Interfaces (NOI): Le nombre d'interfaces. Efferent Coupling (CE): Le nombre de classes dans un packages qui dpendent d'une classe d'un autre package.

*Mtriques (3) Number of Children (NSC): Le nombre total de sous-classes directes d'une classe Depth of Inheritance Tree (DIT): Distance jusqu' la classe Object dans la hirarchie d'hritage.Graphe de dpendances entre packageshttp://metrics.sourceforge.net/update

*BibliographieValtech : Management Agile Christophe Addinquy (27mn) David Gageot (17 mn) Xp ca marche vraiment ? (rgis Medina 18mn)TV4IT : Eric Groise Michel CaraVido Google : DP & Python : http://www.aleax.it/goo_pydp.pdf (2h)Alex Martelli

*Table des matiresLes patterns Grass 5Principes fondamentaux de conception14Processus objet (up-xp)32Processus objet (test-refactoring)52______________________________________Les design patterns70Les design patterns de comportement75Automate76Stratgie86Patron de mthode90Observeur96Visiteur105Memento110Iterateur115Chane de responsabilit121Commande125Interprteur130Mdiateur131Les design patterns de structure132Proxy133Decorateur147Adaptateur158Composite162Faade167Poids mouche171Pont173Les designs patterns de cration175Singleton176Fabrication179Fabrication abstraite186Builder190Prototype195_______________________________________Autres Patterns200Les classes d'analyse201Raii202Patterns et architecture205MVC207Mtriques216Bibliographie219

*Junit 3.8->4

*Junit & DP

*Hritage versus compositionStack pile = new Stack(); pile.push("Bas de la pile"); pile.push("Haut de la pile"); pile.insertElementAt("Perdu", 0); while (!pile.empty()) { System.out.println(pile.pop()); } import java.util.logging.*;public class LoggedList extends ArrayList { private static final Logger LOG = Logger.getLogger("logged lists"); public void add(E element) { LOG.info("Added element: " + e.toString()); super.add(e); } public boolean addAll(Collection c) { for (E e : c) { LOG.info("Added element: " + e.toString()); } super.addAll(c); }

*RMI : SecuritDepuis java2, utiliser la scurit sur le SujetReel et le ClientRajouter System.setSecurityManager(new RMISecurityManager());Les lancer avec l'option :java -Djava.security.policy=policy.all SujetReel grant {permission java.security.AllPermission; };

*RMI :UMLrmiregistry(Sujet)Naming.lookup

*//SujetReel.javaimport java.rmi.*;import java.rmi.server.*;public class SujetReel extends UnicastRemoteObject implements Sujet {public SujetReel() throws RemoteException{super();};public void Afficher(){System.out.println ("Bonjour");}public static void main(String args[]) { try { System.setSecurityManager(new RMISecurityManager()); SujetReel leSujetReel = new SujetReel();Naming.rebind("BonjourDeLoin", leSujetReel);}catch (Exception e) {System.out.println ("excpt");} System.out.println("Le sujet est pret"); }}//Sujet.javaimport java.rmi.*; public interface Sujet extends Remote { public void Afficher() throws RemoteException; }

*// Client.javaimport java.rmi.*;import java.rmi.server.*;import java.rmi.registry.*;

public class Client {

public static void main(String args[]) { System.setSecurityManager(new RMISecurityManager()); try{Sujet monSujet = (Sujet)Naming.lookup("rmi://127.0.0.1/BonjourDeLoin"); monSujet.Afficher();}catch (Exception e) {System.out.println ("excpt");}}}

*RMI :Mise en ouvre

*Automate-Tableau

*Refactoring-MtriquesAvantAvantAprsAprs

*Abuser MetriquesSans DPAvec DP

*LocomotiveSurCoussin lr =new LocomotiveSurCoussin();WagonSurRail wr =new WagonSurRail();lr.Accrocher(wr);lr.Rouler();FabriqueAbstraite f1 ;Locomotive lrail;Wagon wrail ;f1 = new FabriquePourRail();lrail = f1.CreerLocomotive();wrail = f1.CreerWagon();lrail.Accrocher(wrail);lrail.Rouler();f1 = new FabriquePourCoussin();lrail = f1.CreerLocomotive();wrail = f1.CreerWagon();lrail.Accrocher(wrail);lrail.Rouler();La loco sur coussin d'air voleLa wagon sur rail rouleLa loco sur rail rouleLa wagon sur rail rouleLa loco sur coussin d'air voleLa wagon sur coussin d'air vole

*Le Robot

*Le Robot : CompositeComposite

*Mtriques : InstabilityAfferent Coupling (CA): Le nombre de classes hors d'une package qui dpendent d'une classe dans le packageEfferent Coupling (CE): Le nombre de classes dans un packages qui dpendent d'une classe d'un autre package.Instability (RMI): CE / (CA + CE) : Ce nombre vous donnera l'instabilit de votre projet.C'est--dire les dpendances entre les paquets.CA = 0CE = 2RMI = 1CA = 2CE = 0RMI = 0CA = 2CE = 1RMI = 0,33

*Menu projet-propriet : onglet library : ajouter le junit.jar contenu ds l'installe eclipse ***Christopher Alexander a t le premier a propos un catalogue de modles de conception en architecture des btiments et des villes.La rutilisation est une qute de longue date :procdures et fonctions, bibliothquesProgrammation oriente objetLes composants logiciels

*Le nom du modle doit tre parlant, prcis vis--vis du problme. Il vient enrichir le vocabulaire de conception, permettant de travailler un niveau dabstraction plus lev, de les citer dans une conversation de travail ou une documentation.Le deuxime point peut aussi prciser une liste de condition satisfaire pour pouvoir utiliser ce modle.Solution : Ce nest jamais la solution elle-mme qui est donne mais un modle constitu dun ensemble dlments (objets) et leurs relations (la faon de les architecturer) pour former une instance de ce modle de solutionConsquences : Consquence darchitecture lemploi de ce modle, mais aussi plus pragmatiquement impact en temps dexcution et en ressources mmoires.********Voir fichiers c:/observerJavaPlus exemple c# sur la bourse**Itrateur externe : le client demande le parcours et les lments.Itrateur interne : le client fournit une opration excuter sur chaque lment, et le parcours est ralis par litrateur.SauteA : pour les listes tries ou indexes

***La facade nest pas unique mais on na autant de faade que de type dobjets clients de ce systme.La faade peut aussi servir lintrieur du systme dcoupler les sous-systmes et offrir des services de haut niveau quelques entits du systme.Remarque : La faade nest connue que des clients, pas des systmes abstraits.

*La rduction des dpendances de compilation peuvent tre critiques dans le cas de dveloppement consquents (cest le cas si la faade est utilise au travers dune interface, ou classe abstraite, seul la classe concrte de la faade est recompile).Exemple en Java : public sur une classe pour la rendre visible, par dfaut, elle ne lai qu lintrieur de son package, private pour limiter son utilisation ses sous-classes.*Exemple : gestionnaire de fichiers, de fentres, pool unique de connexion BDLa solution habituelle : Une rfrence globale unique, mais on nempche pas dans recrer une autre. De plus, si on ne veut pas linstancier au dmarrage de lapplication, chaque code utilisateur devra tester si elle est dj instancie.Autre solution envisageable : des oprations statiques, mais problme dinitialisation, on doit nouveau tester si elle a t initialise.*SingletonStateObserverStrategieTemplate methodememento

**Voir projet mix sous eclipseAdaptateur decorateur fabrique composite - observeur*Cet exemple viole allgrement le contrat tabli par la documentation de Stack qui stipule que the Stack class represents a last-in-first-out (LIFO) stack of objects. Cette implmentation nave semble parfaitement lgitime premire vue. Trois graves problmes existent nanmoins, une erreur de smantique, une limitation fonctionnelle et un bug. Cela fait beaucoup pour quelques lignes de code. Le premier problme est relativement simple : une liste journalise n'est pas une ArrayList. Le lien smantique introduit par le programmeur est compltement artificiel, mais surtout faux. De cette premire erreur dcoule naturellement la deuxime, notre liste est limite l'implmentation fournie par la classe ArrayList. Que faire si une liste chane est mieux approprie mais que je dsire la journaliser ? Enfin, cette classe enregistre dans le journal tous les ajouts en double lorsque la mthode addAll() est invoque. Ce comportement est d un dtail de l'implmentation d'ArrayList qui appelle add() dans addAll(). Vous ne pouvez pas srieusement prendre en compte ce fait pour votre propre implmentation. Si vous corrigez le bug en retirant la journalisation d'addAll(), que se passera t'il si la prochaine version de l'API change l'implmentation ? Vous perdrez alors la journalisation d'addAll().

Documents

design-patterns-java-1222499509564319-8