Dark Mode

Aller au contenu

Patron de conception

Un article de Wikipedia, l'encyclopedie libre.

Pour les articles homonymes, voir Patron.

En informatique, et plus particulierement en developpement logiciel, un patron de conception (souvent appele design pattern) est un arrangement caracteristique de modules, reconnu comme bonne pratique en reponse a un probleme de conception d'un logiciel. Il decrit une solution standard, utilisable dans la conception de differents logiciels[1].

Un patron de conception est issu de l'experience des concepteurs de logiciels[2][source insuffisante]. Il decrit un arrangement recurrent de roles et d'actions joues par des modules d'un logiciel, et le nom du patron sert de vocabulaire commun entre le concepteur et le programmeur[3]. D'une maniere analogue a un motif de conception en architecture, le patron de conception decrit les grandes lignes d'une solution, qui peuvent ensuite etre modifiees et adaptees en fonction des besoins[4].

Les patrons de conception decrivent des procedes de conception generaux et permettent en consequence de capitaliser l'experience appliquee a la conception de logiciel. Ils ont une influence sur l'architecture logicielle d'un systeme informatique.

Le patron proxy.

Types de patrons

[modifier | modifier le code]

Les patrons de conception ne sont ni des patrons d'architecture ni des idiotismes de programmation.

  • Un patron de conception est la meilleure solution connue a un probleme de conception recurrent.
  • Un patron d'architecture est la meilleure solution connue a un probleme d'architecture recurrent. Il apporte des solutions sur la maniere de concevoir l'organisation a grande echelle (architecture) d'un logiciel en faisant abstraction des details. Il concerne la structure generale d'un logiciel, sa subdivision en unites plus petites, comporte des guides de bonnes pratiques et des regles generales qui ne peuvent pas etre traduites directement en code source[5].
  • Le patron de conception suggere un arrangement, une maniere d'organiser des modules ou des classes. Il decrit une organisation de classes frequemment utilisee pour resoudre un probleme recurrent. Le patron de conception parle d'instances, de roles et de collaboration[5].
  • L'idiotisme de programmation est une construction specifique a un langage de programmation, qui est une maniere usuelle de mettre en oeuvre une solution a un probleme dans ce langage de programmation. Par exemple pour effectuer cent fois une operation, un programmeur en langage C utilise les instructions for (i = 0; i < 100; i++) pour sa ligne de code. L'utilisation d'un idiotisme par le programmeur lui evite d'avoir a remettre en question la structure detaillee du programme et ameliore la qualite du produit[5].

Description

[modifier | modifier le code]

Les patrons servent a documenter des bonnes pratiques basees sur l'experience. Ils proposent des solutions a des problemes qui peuvent etre difficilement resolus par un seul composant : la description de la plupart des patrons implique plusieurs roles qui peuvent etre joues par plusieurs composants d'un logiciel. Par exemple, le patron Observer implique deux roles qui sont le sujet et l'observateur[6].

Les patrons apportent un vocabulaire commun entre l'architecte informatique et le programmeur. Si le programmeur connait le patron de conception observer, alors l'architecte informatique n'aura pas besoin de lui donner de longues explications et le dialogue se limitera a << ici, j'ai utilise un Observer >>[6].

En programmation informatique, les patrons de conception peuvent etre utilises avant, pendant, ou apres le travail de programmation : utilise avant, le programmeur utilisera le patron comme guide lors de l'ecriture du code source ; utilise apres, il servira comme exemple pour relier differents modules de code source deja ecrits, ce qui implique d'ecrire le code source necessaire a leur liaison, et le code qui les fera correspondre au patron de conception ; s'il est utilise pendant le travail de programmation, le programmeur constatera que le code qui vient d'etre ecrit a des points communs avec un patron existant et effectuera les modifications necessaires pour que le code corresponde au patron[7]. La bonne pratique consiste toutefois a n'utiliser un patron qu'une fois qu'il est clair que sa flexibilite est necessaire[8].

Formalises dans le livre du << Gang of Four >> (GoF, Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides (en)) intitule Design Patterns - Elements of Reusable Object-Oriented Software[9] en 1994. Les patrons de conception tirent leur origine des travaux de l'architecte Christopher Alexander dans les annees 70, dont son livre A Pattern Language definit un ensemble de patrons d'architecture.

  • << Chaque patron decrit un probleme qui se manifeste constamment dans notre environnement, et donc decrit le coeur de la solution a ce probleme, d'une facon telle que l'on puisse reutiliser cette solution des millions de fois, sans jamais le faire deux fois de la meme maniere >> -- Christopher Alexander, 1977.
  • << Les patrons offrent la possibilite de capitaliser un savoir precieux ne du savoir-faire d'experts >> -- Buschmann, 1996.

La description d'un patron de conception suit un formalisme fixe :

  • Nom ;
  • Description du probleme a resoudre ;
  • Description de la solution : les elements de la solution, avec leurs relations. La solution est appelee patron de conception ;
  • Consequences : resultats issus de la solution.

Ce formalisme aide surtout a mieux comprendre l'utilisation et la logique interne de chaque patron, mais ne correspond pas a l'usage habituel du terme. Le mot structure serait peut-etre plus adapte.

Un aspect de construction plus important est l'orthogonalite : chaque patron doit correspondre a une approche differente, qui ne repete pas les idees ou strategies presentes dans d'autres patrons. Cette qualite permet au concepteur d'analyser un probleme et d'en resoudre chaque aspect d'une facon organisee, ainsi que de combiner les patrons pour construire une solution. Certains auteurs voient un manque d'orthogonalite dans les patrons GoF, tandis que d'autres en proposent encore davantage (Vlissides, Grand).

Patrons de conception du GoF

[modifier | modifier le code]

Les patrons de conception ont ete formellement reconnus en 1994 a la suite de la parution du livre Design Patterns: Elements of Reusable Software, co-ecrit par quatre auteurs : Gamma, Helm, Johnson et Vlissides (Gang of Four - GoF ; en francais << la bande des quatre >>). Ce livre, devenu un best-seller, decrit vingt-trois << patrons GoF >> et comment s'en servir[10][source insuffisante].

Il existe trois familles de patrons de conception selon leur utilisation :

  • createurs : ils definissent comment faire l'instanciation et la configuration des classes et des objets ;
  • structuraux : ils definissent comment organiser les classes d'un programme dans une structure plus large (separant l'interface de l'implementation) ;
  • comportementaux : ils definissent comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilites) et expliquent le fonctionnement des algorithmes impliques.

Les vingt-trois patrons GoF :

Fabrique et Fabrique abstraite
Ce patron fournit une interface pour creer des familles d'objets sans specifier la classe concrete[11]. Le patron fabrique, ou methode fabrique (en anglais factory ou factory method) est un patron recurrent. Une fabrique simple retourne une instance d'une classe parmi plusieurs possibles, en fonction des parametres qui ont ete fournis. Toutes les classes ont un lien de parente, et des methodes communes, et chacune est optimisee en fonction d'une certaine donnee[10]. Le patron fabrique abstraite (en anglais abstract factory) va un peu plus loin que la fabrique simple. Une fabrique abstraite est utilisee pour obtenir un jeu d'objets connexes. Par exemple pour implementer une charte graphique : il existe une fabrique qui retourne des objets (boutons, menus) dans le style de Windows, une qui retourne des objets dans le style de Motif, et une dans le style de Macintosh. Une fabrique abstraite est obtenue en utilisant une fabrique simple[10].
Adaptateur
Ce patron convertit l'interface d'une classe en une autre interface exploitee par une application. Permet d'interconnecter des classes qui sans cela seraient incompatibles[11]. Il est utilise dans le cas ou un programme se sert d'une bibliotheque de classe qui ne correspond plus a l'utilisation qui en est faite, a la suite d'une mise a jour de la bibliotheque dont l'interface a change. Un objet adaptateur (en anglais adapter) expose alors l'ancienne interface en utilisant les fonctionnalites de la nouvelle[12][source insuffisante].
Pont
Ce patron permet de decoupler une abstraction de son implementation, de telle maniere qu'ils peuvent evoluer independamment[11]. Il consiste a diviser une implementation en deux parties : une classe d'abstraction qui definit le probleme a resoudre, et une seconde classe qui fournit une implementation. Il peut exister plusieurs implementations pour le meme probleme et la classe d'abstraction comporte une reference a l'implementation choisie, qui peut etre changee selon les besoins[13][source insuffisante]. Le patron pont (en anglais bridge) est frequemment utilise pour realiser des recepteurs d'evenements[14].
Monteur
Ce patron separe le processus de construction d'un objet du resultat obtenu. Permet d'utiliser le meme processus pour obtenir differents resultats[11]. C'est une alternative au pattern fabrique. Au lieu d'une methode pour creer un objet, a laquelle est passee un ensemble de parametres, la classe fabrique comporte une methode pour creer un objet -- le monteur (en anglais builder). Cet objet comporte des proprietes qui peuvent etre modifiees et une methode pour creer l'objet final en tenant compte de toutes les proprietes. Ce pattern est particulierement utile quand il y a de nombreux parametres de creation, presque tous optionnels[15][source insuffisante].
Chaine de responsabilite
Le patron chaine de responsabilite (en anglais chain of responsibility) vise a decoupler l'emission d'une requete de la reception et le traitement de cette derniere en permettant a plusieurs objets de la traiter successivement[11]. Dans ce patron chaque objet comporte un lien vers l'objet suivant, qui est du meme type. Plusieurs objets sont ainsi attaches et forment une chaine. Lorsqu'une demande est faite au premier objet de la chaine, celui-ci tente de la traiter, et s'il ne peut pas il fait appel a l'objet suivant, et ainsi de suite[16][source insuffisante].
Commande
Ce patron emboite une demande dans un objet, permettant de parametrer, mettre en file d'attente, journaliser et annuler des demandes[11]. Dans ce patron un objet commande (en anglais command) correspond a une operation a effectuer. L'interface de cet objet comporte une methode execute. Pour chaque operation, l'application va creer un objet different qui implemente cette interface -- qui comporte une methode execute. L'operation est lancee lorsque la methodeexecute est utilisee. Ce patron est notamment utilise pour les barres d'outils[17][source insuffisante].
Composite
Le patron composite (meme nom en anglais) permet de composer une hierarchie d'objets, et de manipuler de la meme maniere un element unique, une branche, ou l'ensemble de l'arbre[11]. Il permet en particulier de creer des objets complexes en reliant differents objets selon une structure en arbre. Ce patron impose que les differents objets aient une meme interface, ce qui rend uniformes les manipulations de la structure. Par exemple dans un traitement de texte, les mots sont places dans des paragraphes disposes dans des colonnes dans des pages ; pour manipuler l'ensemble, une classe composite implemente une interface. Cette interface est heritee par les objets qui representent les textes, les paragraphes, les colonnes et les pages[18][source insuffisante].
Decorateur
Le patron decorateur (en anglais decorator) permet d'attacher dynamiquement des responsabilites a un objet. Une alternative a l'heritage[11]. Ce patron est inspire des poupees russes. Un objet peut etre cache a l'interieur d'un autre objet decorateur qui lui rajoutera des fonctionnalites, l'ensemble peut etre decore avec un autre objet qui lui ajoute des fonctionnalites et ainsi de suite. Cette technique necessite que l'objet decore et ses decorateurs implementent la meme interface, qui est typiquement definie par une classe abstraite[19][source insuffisante].
Facade
Le patron facade (en anglais facade) fournit une interface unifiee sur un ensemble d'interfaces d'un systeme[11]. Il est utilise pour realiser des interfaces de programmation. Si un sous-systeme comporte plusieurs composants qui doivent etre utilises dans un ordre precis, une classe facade sera mise a disposition, et permettra de controler l'ordre des operations et de cacher les details techniques des sous-systemes[20][source insuffisante].
Flyweight
Dans le patron flyweight (en francais poids-mouche), un type d'objet est utilise pour representer une gamme de petits objets tous differents[11]. Ce patron permet de creer un ensemble d'objets et de les reutiliser. Il peut etre utilise par exemple pour representer un jeu de caracteres : un objet factory va retourner un objet correspondant au caractere recherche. La meme instance peut etre retournee a chaque fois que le caractere est utilise dans un texte[20].
Interpreter
Le patron comporte deux composants centraux : le contexte et l'expression[20] ainsi que des objets qui sont des representations d'elements de grammaire d'un langage de programmation[11]. Le patron est utilise pour transformer une expression ecrite dans un certain langage de programmation -- un texte source -- en quelque chose de manipulable par programmation[20] : Le code source est ecrit conformement a une ou plusieurs regles de grammaire, et un objet est cree pour chaque utilisation d'une regle de grammaire. L'objet interpreter est responsable de transformer le texte source en objets[21][source insuffisante].
Iterator
Ce patron permet d'acceder sequentiellement aux elements d'un ensemble sans connaitre les details techniques du fonctionnement de l'ensemble[11]. C'est un des patrons les plus simples et les plus frequents. Selon la specification originale, il consiste en une interface qui fournit les methodes Next et Current. L'interface en Java comporte generalement une methode nextElement et une methode hasMoreElements[10].
Mediator
Dans ce patron il y a un objet qui definit comment plusieurs objets communiquent entre eux en evitant a chacun de faire reference a ses interlocuteurs[11]. Ce patron est utilise quand il y a un nombre non negligeable de composants et de relations entre les composants. Par exemple dans un reseau de 5 composants il peut y avoir jusqu'a vingt relations (chaque composant vers quatre autres). Un composant mediateur est place au milieu du reseau et le nombre de relations est diminue : chaque composant est relie uniquement au mediateur[22][source insuffisante]. Le mediator joue un role similaire a un sujet dans le patron observer et sert d'intermediaire pour assurer les communications entre les objets[23].
Memento
Ce patron vise a externaliser l'etat interne d'un objet sans perte d'encapsulation. Permet de remettre l'objet dans l'etat ou il etait auparavant[11]. Ce patron permet de stocker l'etat interne d'un objet sans que cet etat ne soit rendu public par une interface. Il est compose de trois classes : l'origine -- d'ou l'etat provient, le memento --, l'etat de l'objet d'origine, et le gardien qui est l'objet qui manipulera le memento. L'origine comporte une methode pour manipuler les memento. Le gardien est responsable de stocker les memento et de les renvoyer a leur origine. Ce patron ne definit pas d'interface precise pour les differents objets, qui sont cependant toujours au nombre de trois[24][source insuffisante].
Observer
Ce patron etablit une relation un a plusieurs entre des objets, ou lorsqu'un objet change, plusieurs autres objets sont avises du changement[11]. Dans ce patron, un objet le sujet tient une liste des objets dependants des observateurs qui seront avertis des modifications apportees au sujet. Quand une modification est apportee, le sujet emet un message aux differents observateurs. Le message peut contenir une description detaillee du changement[23][source insuffisante]. Dans ce patron, un objet observer comporte une methode pour inscrire des observateurs. Chaque observateur comporte une methode Notify. Lorsqu'un message est emis, l'objet appelle la methode Notify de chaque observateur inscrit[25][source insuffisante].
Prototype
Ce patron permet de definir le genre d'objet a creer en dupliquant une instance qui sert d'exemple -- le prototype[11]. L'objectif de ce patron est d'economiser le temps necessaire pour instancier des objets. Selon ce patron, une application comporte une instance d'un objet, qui sert de prototype. Cet objet comporte une methode clone pour creer des duplicata. Pour qu'un objet puisse etre clone suivant le langage de programmation il peut etre necessaire de le declarer explicitement. Par exemple en Java la classe de l'objet doit implementer Cloneable[26].
Proxy
Ce patron est un substitut d'un objet, qui permet de controler l'utilisation de ce dernier[11]. Un proxy est un objet destine a proteger un autre objet. Le proxy a la meme interface que l'objet a proteger. Un proxy peut etre cree par exemple pour permettre d'acceder a distance a un objet (via un middleware). Le proxy peut egalement etre cree dans le but de retarder la creation de l'objet protege -- qui sera cree immediatement avant d'etre utilise. Dans sa forme la plus simple, un proxy ne protege rien du tout et transmet tous les appels de methode a l'objet cible[14].
Singleton
Ce patron vise a assurer qu'il n'y a toujours qu'une seule instance d'une classe en fournissant une interface pour la manipuler[11]. C'est un des patrons les plus simples. L'objet qui ne doit exister qu'en une seule instance comporte une methode pour obtenir cette unique instance et un mecanisme pour empecher la creation d'autres instances[16].
State
Ce patron permet a un objet de modifier son comportement lorsque son etat interne change[11]. Ce patron est souvent utilise pour implementer une machine a etats. Un exemple d'appareil a etats est le lecteur audio -- dont les etats sont lecture, enregistrement, pause et arret. Selon ce patron il existe une classe machine a etats, et une classe pour chaque etat. Lorsqu'un evenement provoque le changement d'etat, la classe machine a etats se relie a un autre etat et modifie ainsi son comportement[27][source insuffisante].
Strategy
Dans ce patron, une famille d'algorithmes est encapsulee de maniere qu'ils soient interchangeables. Les algorithmes peuvent changer independamment de l'application qui s'en sert[11]. Il comporte trois roles : le contexte, la strategie et les implementations. La strategie est l'interface commune aux differentes implementations -- typiquement une classe abstraite. Le contexte est l'objet qui va associer un algorithme avec un processus[20].
Template method
Ce patron definit la structure generale d'un algorithme en deleguant certains passages. Permettant a des sous-classes de modifier l'algorithme en conservant sa structure generale[11]. C'est un des patrons les plus simples et les plus couramment utilises en programmation orientee objet. Il est utilise lorsqu'il y a plusieurs implementations possibles d'un calcul. Une classe d'exemple (anglais template) comporte des methodes d'exemple, qui, utilisees ensemble, implementent un algorithme par defaut. Certaines methodes peuvent etre vides ou abstraites. Les sous-classes de la classe template peuvent remplacer certaines methodes et ainsi creer un algorithme derive[21].
Visitor
Ce patron represente une operation a effectuer sur un ensemble d'objets. Permet de modifier l'operation sans changer l'objet concerne ni la structure[11]. Selon ce patron, les objets a modifier sont passes en parametre a une classe tierce qui effectuera des modifications. Une classe abstraite Visitor definit l'interface de la classe tierce. Ce patron est utilise notamment pour manipuler un jeu d'objets, ou les objets peuvent avoir differentes interfaces, qui ne peuvent pas etre modifies[20].

Patrons GRASP

[modifier | modifier le code]

Les patrons GRASP (general responsibility assignment software patterns (ou principles)) sont des patrons crees par Craig Larman qui decrivent des regles pour affecter les responsabilites aux classes d'un programme oriente objet pendant la conception, en liaison avec la methode de conception BCE (pour boundary control entity -- en francais MVC << modele vue controleur >>)[28][source insuffisante] :

  • expert ;
  • createur ;
  • faible couplage ;
  • forte cohesion ;
  • controleur ;
  • polymorphisme ;
  • indirection ;
  • fabrication pure ;
  • protection des variations.

Autres patrons de conception

[modifier | modifier le code]
Object Pool
Ce patron permet d'economiser les temps d'instanciation et de suppression lorsque de nombreux objets ont une courte duree d'utilisation. Il consiste a administrer une collection d'objets qui peuvent etre recycles. Une methode du Pool delivre un objet soit par une nouvelle instanciation, soit par recyclage d'un objet perime. Lorsque les objets arrivent a la fin de leur cycle de vie, ils sont remis a la disposition du Pool pour un futur recyclage. Dans la phase d'instanciation, le Pool peut instancier plus d'un objet a la fois si l'algorithme d'instanciation a une complexite meilleure que O(n). Le patron Object Pool est particulierement utile lorsque le nombre total de cycles de vie est tres grand devant le nombre d'instances a un moment precis et que les operations d'instanciation et/ou suppression sont couteuses en temps d'execution par rapport a leur recyclage.
Modele-vue-controleur
Combinaison des patrons observateur, strategie et composite, ce qui forme ainsi un patron d'architecture.
Inversion de controle
Injection de dependances

Notes et references

[modifier | modifier le code]
  1. | (en) Rajib Mall, Fundamentals of Software Engineering, PHI Learning Pvt. Ltd. (ISBN 9788120338197), p. 266.
  2. | Laurent Debrauwer, Design patterns pour Java : Les 23 modeles de conception : descriptions et solutions illustrees en UML 2 et Java, ENI, 2009 (ISBN 978-2-74605057-0).
  3. | (en) Frank Buschmann, Kevlin Henney et Douglas C. Schmidt, Pattern-oriented software architecture: On patterns and pattern languages, John Wiley and Sons, 2007 (ISBN 9780471486480), p. 13.
  4. | (en) Linda Rising, The Patterns Handbook: Techniques, Strategies, and Applications, Cambridge University Press, 1998 (ISBN 9780521648189), p. 311.
  5. | a b et c (en) Rajib Mall, Fundamentals of Software Engineering, op. cit., p. 267
  6. | a et b (en) Buschmann, Henney et Schmidt, Pattern-oriented software architecture: On patterns and pattern languages, op. cit.
  7. | (en) Stephen Hendrick Kaisler, Software Paradigms, John Wiley and Sons, p. 39, 2005 (ISBN 9780471483472).
  8. | (en) Bill Venners, << Erich Gamma on Flexibility and Reuse, A Conversation with Erich Gamma, Part II >>. << Bill Venners: So what do the XP guys do first, if they don't use patterns? They just write the code? Erich Gamma: They write a test. Bill Venners: Yes, they code up the test. And then when they implement it, they just implement the code to make the test work. Then when they look back, they refactor, and maybe implement a pattern? Erich Gamma: Or when there's a new requirement. >>
  9. | Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (trad. Jean-Marie Lasvergeres), Design Patterns - Catalogue de modeles de conceptions reutilisables, France, Vuibert, , 490 p. [detail des editions] (ISBN 2-71178-644-7)
  10. | a b c et d (en) James William Cooper, Java Design Patterns: A Tutorial, Addison-Wesley Professional - 2000 (ISBN 9780201485394).
  11. | a b c d e f g h i j k l m n o p q r s t u et v (en) Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Pearson Education - 1994 (ISBN 9780321700698).
  12. | (en) Steve Holzner, Design Patterns For Dummies, John Wiley & Sons, , 308 p. (ISBN 978-0-470-04696-8, lire en ligne)
  13. | (en) Stephen Stelting - Olav Maassen, Applied Java Patterns, Prentice Hall Professional - 2002 (ISBN 9780130935380).
  14. | a et b (en) Dustin Diaz - Ross Harmes, Pro JavaScript Design Patterns, Apress - 2007 (ISBN 9781430204961).
  15. | (en) Joshua Bloch, Effective Java, Addison-Wesley Professional - 2008 (ISBN 9780132778046).
  16. | a et b (en) Carlo Chung, Pro Objective-C Design Patterns for iOS, Apress - 2011 (ISBN 9781430233305).
  17. | (en) Andrei Alexandrescu, Modern C++ Design: Generic Programming and Design Patterns Applied, Addison-Wesley Professional - 2001 (ISBN 9780201704310).
  18. | (en) Mark Grand, Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML, Volume 1, John Wiley & Sons - 2003 (ISBN 9780471449331).
  19. | (en) Joey Lott, Danny Patterson, Advanced ActionScript with Design Patterns, Adobe Press (ISBN 9780132701372).
  20. | a b c d e et f (en) Christopher G. Lasater, Design Patterns, Jones & Bartlett Publishers - 2010 (ISBN 9781449612887).
  21. | a et b (en) Partha Kuchana, Software Architecture Design Patterns in Java, CRC Press - 2004 (ISBN 9780203496213).
  22. | (en) John Hunt, Scala Design Patterns: Patterns for Practical Reuse and Design, Springer Science & Business Media - 2013 (ISBN 9783319021928).
  23. | a et b (en) Addy Osmani, Learning JavaScript Design Patterns, O'Reilly Media, Inc. - 2012 (ISBN 9781449334871).
  24. | (en) Joey Lott - Danny Patterson, Advanced ActionScript with Design Patterns, Adobe Press (ISBN 9780132701372).
  25. | (en) Chaur Wu - Tom Fischer - Pete Stromquist - John Slater, Professional Design Patterns in VB .NET: Building Adaptable Applications, Apress - 2003 (ISBN 9781430207832).
  26. | (en) << Java(r) Platform, Standard Edition & Java Development Kit Version 21 API Specification >>, sur docs.oracle.com (consulte le )
  27. | (en) William Sanders - Chandima Cumaranatunge, ActionScript 3.0 Design Patterns: Object Oriented Programming Techniques, O'Reilly Media, Inc. - 2007 (ISBN 9780596554842).
  28. | Craig Larman, UML 2 et les Design Patterns, 3e ed. (ISBN 2-7440-7090-4).

Sur les autres projets Wikimedia :

Bibliographie

[modifier | modifier le code]

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]
v * m
Creation
Structure
Comportement
Fonctionnel
Patron d'architecture
Autres patrons
v * m
Gestion de la qualite logicielle
Indicateurs de qualite (ISO/CEI 9126)
Comprehension et controle du code source
Tests
Metriques
Remaniements
Principes de programmation
SOLID
Mauvaises pratiques
Antipatterns
Code smells
Voir aussi : Genie logiciel, Software craftsmanship, Degradation logicielle