Discussion :

[Bktero]

Bonjour,

Je reviens avec un nouveau super sujet !

Aujourd'hui, le but du jeu est de faire du monitoring de variables sur un système embarqué. Un genre de probe / oscilloscope de variables. Appelons cette classe Probe pour le moment. La partie PC pour faire de l'affichage est OK, ce qui me titille est la manière de récupérer les données. En fait, ce n'est pas le PC qui va envoyer les données, c'est le système embarqué qui va envoyé des données formatées sur une liaison série. L'idée est qu'il aura une liste de variables connues et les valeurs seront envoyées régulièrement.

Mon questionnement est sur la manière de "surveiller" ces variables. Probe exposera des méthodes pour enregistrer des variables à surveiller. Un code tout simple ressemblerait à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class Probe {
public:
    void watch(const int& integer) {
        integer_m = &integer;
    }
 
    void monitor() const {
        if (integer_m) {
            std::cout << *integer_m << std::endl;
        }
    }
 
private:
    const int* integer_m = nullptr;
};
 
int main() {
    Probe probe;
 
    int a = 42;
    probe.watch(a);
 
    probe.monitor();
 
    a = 666;
    probe.monitor();
}

Et il affiche bien 42 et 66.

Là où ça se complique, c'est pour surveiller une classe, notamment les champs privés. Prenons cette classe à surveiller :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
class Translator {
public:
    enum Locale { // ...
    };
    Translator(Locale locale);
    std::string translate(std::string original);
private:
    Locale locale_m;
};

Comment faire ? Je ne vois pas trop Probe avoir une méthode par type d'objets à supporter. Et je ne vois pas trop non plus Probe est ami avec tout le monde.

Mon idée serait que la classe Probe reste simple. Elle ne sait faire des watch() que sur des types de bases. Ensuite, chaque classe qui aurait besoin d'être surveiller se verrait adjointe d'une classer helper. Par exemple, TranslatorWatcher. Cette classe serait ami de Translator et serait capable de récupérer les données privées intéressantes, les transformant si besoin pour caler aux capacités de Probe. Je multiplie un peu les classes mais je reste très modulaire.

Qu'en pensez-vous ? Avez-vous de brillantes idées à me communiquer ?

Merci d'avance !

[bacelar]

Pas possible de faire le DP Observer ?

[prgasp77]

Bonjour,

si une telle possibilité est convenable, un visiteur serait approprié :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
class Probe;
struct Watchable { virtual void watch(Probe& p) const = 0; };
 
// ...
 
class Coordinates : public Watchable
{
    double x, y;
public:
    void watch(Probe& p) const override { p.watch(x); p.watch(y); }
};
 
int main()
{
    Coordinates c;
    // ...
    Probe p;
    c.watch(p);
    probe.monitor();
}

Chaque classe pouvant être monitorée doit connaitre l'interface Watchable, c'est le gros désavantage. Mais pas d'amis. Chaque classe est responsable d'exposer à une sonde ses propres variables.

[Bktero]

Merci pour vos réponses !

Je n'avais pas du tout pensé à Observer/Observable. Je dois pouvoir surveiller des variables de types de base et potentiellement des registres du MCU directement donc il faudrait faire des wrappers autour. Ca inverse aussi le pattern car j'ai un observer et plusieurs observables.

J'avais pensé à Visitor mais je ne le connais pas très bien et je n'ai pas creusé dans cette direction. Cela ressemble à ce que mes collègues proposaient de faire je pense.

Dans tous les cas, on se retrouve à devoir faire une brèche dans le couplage entre entité. Je vais faire des essais pour voir comment respecter SOLID au maximum.

J'ai testé un peu la solution que j'évoquais. J'arrive à des trucs comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
template<typename T>
class ProbeBinder {
public:
    virtual void attach(Probe& probe, const T& t) = 0;
};
 
 
class Translator {
public:
    // blabla
private:
    Locale locale_m;
    friend class TranslatorProbeBinder;
};
 
class TranslatorProbeBinder : public ProbeBinder<Translator> {
public:
    void attach(debug::Probe& probe, const Translator& t) override {
        probe.watch(t.locale_m);
    }
};
 
int main() {
    Translator translator;
    TranslatorProbeBinder helper;
    helper.attach(probe, translator);
}

L'interface ProbeBinder c'est à uniformiser les nommages des classes qui vont faire le lien, on pourrait s'en passer techniquement. Ce qui est pas mal dans cette solution, c'est les objets binders sont temporaires, on ne garde rien en mémoire une fois le binding fait. Ils servent "juste" à casser l'encapsulation des champs privés. Fondamentalement, c'est comme la proposition avec Watchable, sauf que ça sépare en 2 classes (je me dis que ça respecte un peu plus le S de SOLID...) et que ça gagne un peu de mémoire (comme je suis en embarqué c'est toujours ça de pris).

[prgasp77]

À partir du moment où vous laissez un mécanisme externe interférer avec la représentation de vos classes, vous pouvez ranger SOLID au placard. Au mieux, vous pouvez respecter SOLID si votre Probe est ignorée, ce qui est déjà pas mal.

Mais on ne fait pas de watchdog sans casser de pattern.

[koala01]

(je me dis que ça respecte <snip> que ça gagne un peu de mémoire (comme je suis en embarqué c'est toujours ça de pris).

Tu te dis que tu gagne un peu de mémoire, ou tu as des mesures concrètes pour confirmer tes dires

Et, sinon, faisons "simple": un système de "callback" (idéalement, j'irais même jusqu'à une système de signaux et de slots, mais, en embarqué ... /p) d'une fonction par valeur à surveiller, ce ne serait pas possible

Je sais pas, moi, un genre de callback onXYGChanged(newValue), dans lequel tu indiquerait, pour chaque variable à surveiller, ce qui doit être fait