Doc: Add a text explaining why I won't implement de decorator pattern

This commit is contained in:
Namu
2025-10-02 09:57:39 +02:00
parent a26a8c6cf1
commit 2ad93f4b91
2 changed files with 14 additions and 2 deletions

View File

@@ -1,5 +1,3 @@
import utils.NotificationManager;
void main(String[] args) {
final var app = new Application();
app.run();

View File

@@ -2,6 +2,20 @@ package utils;
import entities.Notification;
/**
* Ces approches ne seront pas implémentées ici, car elles pourraient alourdir le code sans apport clair.
* Par exemple, un builder pourrait être utile pour construire des notifications (objets complexes),
* ou des stratégies pourraient être envisagées pour des fonctionnalités comme la datation.
* Les design patterns ne sont pas des solutions universelles : leur utilisation doit être justifiée par un besoin concret.
* Le code actuel ne respecte pas pleinement les principes SOLID, ce qui peut rendre sa maintenance plus difficile.
* L'ajout de patterns comme le Singleton (considéré comme un anti-pattern dans certains contextes,
* notamment parmi les principes STUPID) ne résoudrait pas nécessairement ces problèmes.
* Pour s'entraîner, les Katas sont une excellente alternative : ce sont des exercices simples et variés,
* idéaux pour explorer les design patterns de manière propre et progressive.
* Ils permettent aussi de comparer différentes solutions pour un même problème, ce qui est très formateur !
*/
public abstract class BaseDecorator {
protected Notification notification;