Présenté par chaima limayem

Design Patternes

Patterns de conception à connaître en Angular

Pour développer des applications de qualité il est nécessaire d’avoir une bonne connaissance des
patterns de conception existant.

MVC Pattern
-correspond à l’architecture d’un projet composé de trois parties bien distinctes.

- Les modèles représentent les données reçu d’un serveur /stockage local / saisie par l’utilisateur

-Les vues correspondent à l’interface utilisateur (le template HTML).

- les contrôleurs permettent de faire le lien entre les deux couches précédentes. ( les modèles et
les vues )

Avec Angular.js par default on utilise “two way data binding” c a d :

Si on applique modification dans les modèles qui sont représentés par les vues ces modifications
vont changées aussi le modèles original
Dependency Injection Pattern
-L'injection de dépendances (DI) est un pattern de conception important pour développer des
applications à grande échelle.

- DI, est utilisé dans la conception d'applications Angular pour augmenter l’efficacité et la
modularité.

-En effet dans le constructeur des classes (exp composants, directives, services) on demande des
dépendances (services ou des objets).

Et un système externe (l’injecteur) qui se charge de créer l’instance en fonction de la

configuration.

Cela facilite ainsi le développement mais aussi les tests.

SOLID Pattern
-Le design pattern SOLID est un ensemble de cinq principes adaptés à la programmation
informatique orientée objet.

-Il a pour but de rendre le design des logiciels plus compréhensible, flexible et maintenable.

-Ces principes permettent de mettre en évidence les bonnes pratiques à suivre mais ils sont
abstraits

1. Responsabilité unique :

-Chaque fichier (classe / fonction / module / section) ne devrait avoir qu'une seule
responsabilité, c'est à dire qu'il doit permettre de faire une unique chose.

- Il faut donc découper la logique en autant de classe et fichiers que nécessaire.

-De plus il doit y a voir une place pour tous types de fichiers et chaque fichiers doit être à la
bonne place.

2. Ouvert-fermé :
-Chaque classe doit être ouverte à l’extension mais fermée à la modification.

-Il doit pouvoir être possible d’étendre les fonctionnalités en ajoutant du code uniquement
mais sans changer le code existant.

- De cette façon il y a moins de risque de casser la logique de fonctionnement.

 3. Principe d'inversion des dépendances :
Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau mais les
deux doivent dépendre d’abstractions. (Ex : dependency injection pattern, adapter pattern)

Strategy Pattern
-Le strategy design pattern consiste à séparer l'exécution d'une logique métier de l'entité qui
l'utilise et donnez à cette entité un moyen de basculer entre différentes formes de logique.

Visitor Pattern
-Le visitor pattern est utile si vous avez plusieurs classes qui héritent de la même classe de base
ou implémentent la même interface.

-Le modèle de visiteur permet d'éviter les blocs if-else ou le switch/case et le forçage de typage.

-En effet le but est d'ajouter de nouveaux comportements à la hiérarchie de classes existante
sans modifier aucun code existant.

Model-Adapter Pattern
Le design pattern model-adapter permet de transformer le format de données récupérées depuis
une source externe dans un format de données adapté pour être consommé par le client Angular.

Lazy Pattern
-Le design pattern lazy permet de développer des applications scalables et performantes

- le principe de ce pattern est de fournir une application découpée en plusieurs parties

indépendantes les unes des autres.

-→ réduire la taille de l’application principale

→ avoir ensuite différents modules qui seront téléchargés par l’utilisateur s’il souhaite accéder a
cette partie précise de l’application.

Singleton Pattern
-Ce pattern permet de garantir qu'il n'y a qu'une seule instance de votre classe.

- but : contrôler la portée des variables à l'intérieur.

-Il est géré à l'aide d'une méthode publique getInstance qui garantit le seul et unique moyen
d'accéder à la classe.
Factory pattern
-Ce pattern est très simple mais très utile

Utilisé si : vous devez créer des différentes instances d’une même classe parente en fonction de
certaines conditions.

-La factory définit une interface de création de l'objet

-Cette interface contient généralement une seule méthode publique.

-Ensuite, il est possible d’avoir différentes implémentations de cette interface factory avec
chacune leurs propres logiques pour instancier les objets.

Command pattern
-Le but de ce modèle est d'encapsuler une commande à l'intérieur d'un objet.

- La commande peut être de tout type, par exemple une action synchrone ou même une requête
asynchrone.

-Grâce à cela, vous pouvez avoir une liste de commandes que vous pouvez facilement réutiliser,
combiner et maintenir dans votre application.

Decorator pattern
-Le pattern de conception de décorateur est une alternative aux sous-classes pour étendre un
objet en utilisant la composition au lieu de l'héritage

-En fait, le décorateur attache des responsabilités supplémentaires à un objet.

Le concept principal est d'avoir un objet qui enveloppe un autre objet.