Infrastructure Java · Egothor
conflux
Une bibliothèque Java volontairement réduite pour les cas où des composants indépendants doivent partager un peu d’état typé et réagir à ses changements — sans transformer ce besoin de coordination en framework d’injection de dépendances ou en architecture d’application.
Le petit problème qui devient souvent un grand graphe de dépendances
Un composant calcule une valeur. Plusieurs composants sans lien direct ont besoin de la valeur courante, et certains doivent réagir immédiatement à son changement. La solution naïve consiste à câbler des références partout ; la solution « entreprise » peut importer un framework entier. conflux occupe volontairement l’espace entre les deux.
- Clés typées pour réduire les incohérences d’intégration.
- Valeur courante + événements pour de nombreux cas UI et infrastructure.
- Listeners faibles pour limiter la rétention accidentelle.
- Périmètre réduit pour une intégration facile dans des systèmes plus vastes.
Un contexte typé plutôt qu’une map gouvernée par des chaînes
Le contexte utilise des clés typées : le contrat comprend le nom et le type Java attendu. Un même nom ne peut pas signifier silencieusement Integer dans un composant et String dans un autre. L’état partagé devient plus facile à raisonner et une classe fréquente d’erreurs est rapprochée du point de déclaration.
Key<Integer> COUNT = Key.of("count", Integer.class);
Ctx.INSTANCE.put(COUNT, 42);
int current = Ctx.INSTANCE.get(COUNT);
Ctx.INSTANCE.addListener(COUNT, value -> refreshView(value));État courant partagé
Les composants récupèrent la valeur sans connaître le producteur ni transporter sa référence dans toute l’application.
Notification de changement
Les listeners réagissent aux mises à jour, évitant le polling continu pour les consommateurs orientés événements.
Références faibles
Une souscription oubliée ne doit pas automatiquement faire de l’event bus le propriétaire de la durée de vie de chaque listener.
Usage concurrent
L’implémentation utilise collections concurrentes et gestion copy-on-write pour rester utilisable entre threads applicatifs.
Volontairement pas un framework applicatif
conflux ne cherche pas à gérer construction d’objets, configuration, scheduling ni logique métier. Sa valeur est au contraire un contrat étroit à ajouter lorsqu’un petit nombre de modules indépendants ont besoin d’un point commun.
Ce périmètre réduit permet aussi d’utiliser la bibliothèque comme infrastructure d’un système plus large : elle résout un problème de coordination et laisse l’architecture à l’application.