Programmer des évènements asynchrones dans une classe ?

Bonjour,

Je pense essayer de développer une classe façade pour simplifier l'utilisation de la classe d'acces aux API du broker Interactive Broker.

Interactive Broker fournit une classe avec des callbacks, car certaines fonctions sont asynchrones.
Même le téléchargement des données historiques utilise un callback.
On déclenche le téléchargement par une méthode.
On récupère les données dans une autre méthode.

Quelle est la meilleure façon d'implémenter des fonctions asynchrones de ce type dans une classe, pour que cette classe soit robuste, facile d'implémentation etc ?
Existe-t-il un design pattern pour traiter ce type de problème ?

Merci,

Langage Java.

sans parler de design pattern, la première question est de savoir si vous voulez que votre façade "masque" les callbacks ou bien est-ce qu'elle devra en fournir aussi.
Ce n'est pas une question anodine car elle dimensionne la taille du code qui sera "derrière" la facade et éventuellement aussi pour résoudre les questions de temps de réponse.
- W

Citation:

---

la première question est de savoir si vous voulez que votre façade "masque" les callbacks ou bien est-ce qu'elle devra en fournir aussi.

---

Ce que je souhaite c'est que la classe façade encapsule tout ce qui concerne la récupération des données historiques.
D'un point de vue conception ça me parait souhaitable.
Que le programme qui utilise la classe façade demande les cotations de telle valeur, de telle date à telle date, et reçoive en retour une ArrayList.
Que le programme n'ai pas à gérer la réception au fil de l'eau des données, la détection de fin d'envoi de données, l'éventuelle détection d'une coupure de connexion, etc.
En conclusion je pense que c'est à la classe façade de gérer les callbacks, pas au programme utilisateur de la classe.

Ouch, il y a du boulot alors!
Jetez un œil au pattern POSA "half-sync/half-async".
- W

Citation:

---

Envoyé par tintin92

Ce que je souhaite c'est que la classe façade encapsule tout ce qui concerne la récupération des données historiques.
D'un point de vue conception ça me parait souhaitable.
Que le programme qui utilise la classe façade demande les cotations de telle valeur, de telle date à telle date, et reçoive en retour une ArrayList.
Que le programme n'ai pas à gérer la réception au fil de l'eau des données, la détection de fin d'envoi de données, l'éventuelle détection d'une coupure de connexion, etc.
En conclusion je pense que c'est à la classe façade de gérer les callbacks, pas au programme utilisateur de la classe.

---

je ne sais pas, mais ça me semble bizarre tout ça..

Vous utilisez des classes, des modèles, etc etc mais vous raisonnez en sens inverse de la séparation...


Encore une fois, une interface doit être interchangeable sans modifier le reste de l'appli, et réciproquement une BD doit être interchangable sans changer le coprs de l'appli...

C'est le but de fond des classes, des couches, etc etc...

Il me semble logique que la classe 'haut niveau" a) n'a aucune connaissance d'où proviennent les données ni de comment on les obtient b) utilise un tableau "données", éventuellement mis à jour.

La classe "haut niveau" devrait juste avoir une "méthode" demande_données et une "méthode" utilise_données, qui ne font qu'appeler des classes de plus bas niveau.

Et que ces méthodes ne "retournent" qu'une fois toutes les données obtenues, la méthode "demande" faisant elle-même appel à une autre "récupère", qui elle (éventuellement avec encore un autre étage) s'occupe de d'envoyer la commande, récupérer, vérifier etc etc...

Ce n'est pas le premier post que je vois dans ce sens, et je m'en étonne toujours... Pourquoi utiliser des classes et des langages objets si c'est pour lier le haut avec le bas ??