Doc: Add a text explaining why I won't implement de decorator pattern
This commit is contained in:
@@ -1,5 +1,3 @@
|
||||
import utils.NotificationManager;
|
||||
|
||||
void main(String[] args) {
|
||||
final var app = new Application();
|
||||
app.run();
|
||||
|
||||
@@ -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;
|
||||
|
||||
|
||||
Reference in New Issue
Block a user