---
# System prepended metadata

title: 'Laboratoire design pattern n°3 - Composite, decorator & state'

---

# Laboratoire design pattern n°3 - Composite, decorator & state
/*-----------
Design Patterns
Labo 3
Équipe 1 : Bruno Costa, Diogo Lopes Da Silva, Matthieu Barbot
-----------*/

## 1. Structure source
Le composite est composé de deux classes Basket et Fruit, le basket correspond à une branche et le fruit à une feuille. Les deux classes surchargent une méthode show() qui affiche le (ou les) et indique ou non la présence de pépins.
Pour le decorator on a une classe decorator de base et des decorators spécifiés qui héritent de la classe de base et prennent en arguement un decorator.
L'affichage se fait de manière récursive de decorator en decorator.
Pour le state, il y a trois classes différentes qui correspondent au trois étapes de la commande. Dès qu'un state est appelé, il affiche la description de la commande et défini le prochain state.
## 2. Améliorations possibles
- On pourrait faire en sorte qu'on puisse choisir si on overlap les décorateurs ou non. Actuellement dans notre code, les décorateurs se mettent l'un sur l'autre.
- Faire une interface graphique.
## 3. Les DPs
### Composite
Le composite ayant déjà été étudié par le passé, les détails le concernant seront omis.
### Decorator
Le décorateur est un design pattern qui permet d'ajouter ou d'attacher dynamiquement des responsabilités et des fonctionnalités à un objet.
#### Faiblesses
- Demande une classe pour chaque type de décorateur ce qui fait que le projet contient beaucoup de classes en tout.
- Il est faible, il ne boit pas assez de lait.
#### Forces
- Permet une grande flexibilité de code
- Évite une surcharge d'utilisation d'héritage
### State
L'état est un design pattern qui permet de changer le comportement d'un objet via un état changé dynamiquement.
Ce design pattern s'inspire du modèle des machines d'états.
#### Faiblesses
- Une classe par état qui peut être remplacée par un état.
- Chaque changement de state est définitif. Difficile de faire marche arrière.
#### Forces
- Le changement d'état est automatique.
- L'amélioration de l'implémentation est facile.
## 4. Conclusion
Le programme actuel permet à un client de commander des fruits avec ou sans pépins et de payer la commande. Cette commande suit une logique d'état précise et définie. De plus, avant de finir la transaction, l'utilisateur peut afficher sa commande avec des petits décorateurs.
Finalement, la phrase : "Utiliser trop de design pattern, tue le design pattern" est vrai.
