Ah:

Dans le génie logiciel (conception et réalisation de logiciels), on utilise différentes manières de résoudre certains problèmes.

Il se trouve que ces "manière de résoudre" sont souvent les mêmes.

Par exemple, on utilise souvent un singleton pour s'assurer qu'il n'y a qu'un seul exemplaire d'un programme en mémoire, ou bien une seule instance d'un objet à la fois.

L'itérateur va permettre d'accéder séquentiellement aux éléments d'une collection
(Par exemple pour demander à un objet de donner petit à petit ses données (sans avoir à tout envoyer d'un coup)).

L'observeur qui permet de prévenir un ensemble de classes de l'arrivée d'un évènement.

etc.


Les "design patterns" essaient justement de lister ces façons de faire, et les problèmes qu'ils permettent de résoudre.


C'est un livre qui est à l'origine de ça: "Design patterns" justement.




Les Design Patterns sont principalement destinées à la programmation orientée objet.


A noter que généralement il est assez difficile de vraiment les maîtriser (le bouquin est énorme), et qu'à force de vouloir faire rentrer à tout prix ses problèmes dans les cases des design patterns, on peut perdre du temps.

D'un autre côté, ça peut être une aide pour simplifier ses développements sur certains cas (à condition que le langage utilisé supporte le concept.)