Ces dernières années, l’informatique a beaucoup évolué et observé de profonds changements, que ce soit en termes de préférence dans les langages ou bien de conception dans les applications. Il était devenu important d’essayer de normaliser certaines techniques de programmation afin de faciliter pour le développeur la conception et la maintenance de l’application.
Cette normalisation a été popularisée par le Gang of Four et leur réflexion autour des Design Patterns (Patrons de conception en Français).
Mais qu’est-ce que le Gang of Four ? Un Design pattern ?
LE GOF EN BREF
Le GoF désigne ainsi les 4 informaticiens : Erich GAMMA, Richard HELM, Ralph JOHNSON et John VLISSIDES. Ils ont présenté leur réflexion dans un ouvrage « Design Pattern : Elements of Reusable Object-Oriented Software», publié en 1994 et édité par Addison-Wesley.
 
LES DESIGN PATTERNS
Définition : Un Design Pattern nomme, encourage et décrit une conception générique sur un problème d’architecture récurrent en programmation orienté objet (OOP en anglais). Il décrit le problème, la solution, quand l’appliquer et ses conséquences. Il donne aussi des conseils d’implémentations avec exemples. La Solution est un arrangement d’objets et de classes qui résoudront le problème.  Cette dernière est également adaptée et implémentée pour résoudre notre problème dans un contexte particulier.[1]
Bon en gros, un pattern c’est :

• Proposer des cas pratiques génériques, connus de l’ensemble des développeurs.
• Permettre de moduler notre code selon le métier (séparer les domaines par exemple l’instanciation du code métier)
• Un code plus maintenable.

Ces méthodes de conception, au nombre de 23, sont regroupées en 3 grandes familles :

• 5 patterns de conception (Creational)
• 7 patterns de structure (Structural)
• 11 patterns de comportement (Behavioral)

Nous allons analyser chacune de ces méthodes, en essayant d’illustrer nos propos au travers d’exemples concrets.

Patterns de Création (Creational Pattern)

Les Patterns de création vont s’attacher avant tout à l’instanciation des objets à la place du développeur. Le but est de simplifier la tâche du développeur en cachant la complexité que peut être la création d’objets très pointus. (Comment créer  l’objet ? Dois-je lui initialiser ses attributs à la création ?  Sur quel objet je vais travailler au final ? …)

Use case

Vous êtes fraîchement recruté en tant que développeur et votre chef vous confie la mission de développer une application (Hé oui !).
Cette application devra :

• analyser des fichiers ;
• valider les fichiers à envoyer ;
• envoyer à un destinataire défini.

Ne connaissant pas (encore) le fonctionnel, nous allons dans un premier temps nous intéresser à la conception logique de l’application, c’est-à-dire la récupération des fichiers.
La suite dans un prochain article.
[1] Traduction selon l’ouvrage du GoF (page 360): A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized, and implemented to solve the problem in a particular context.