Discussion :

[poukill]

(ça fait 10 minutes que je me torture l'esprit pour une ligne de question... )

Un Composant Face au Plasma ne possède pas des Points de Controles, d'un point de vue terre à terre.
Cepedant, pour l'implémentation, oui, CFP va avoir besoin de PDC. Parce que je lui ai donné ce rôle...

Le truc génant pour moi c'est les histoires de contructeurs (cf mon message plus haut).
Mais ta question m'a permis de trouver la réponse: oui il faut que je laisse PDC. J'en suis maintenant convaincu.

Et pour mon message d'avant, qu'en penses-tu?

[poukill]

Un oubli : quelle différence y a t-il entre mettre :

Code :

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

PDC *pdc

ou bien

Code :

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

PDC pdc

en attribut privé (d'un point de vue conception). Dans la mesure où il n'y a pas d'héritage, les deux peuvent se faire. Pourquoi l'un par rapport à l'autre ?

[Matthieu Brucher]

Une classe seule, ce n'est pas aberrant

On utilise un pointeur pour l'agrégation, soit on peut ne pas avoir de PDC, soit le PDC est à partager entre instances.
On utilise la valeur pour la composition, on a une et une seule instance de PDC par instnace englobante.

Par exemple, ça peut être une règle.

[poukill]

C'est un énoncé clair et précis.
Je vais donc rester sans pointeurs...

[poukill]

Dans la logique évoquée par Luc, chaque classe a un rôle à jouer. Bien. Maintenant, supposons que j'ai déterminé que ce soit la classe Ecran qui stocke coeff_mul. C'est la classe qui est la plus enclin à stocker cet attribut.

Pb: C'est peut être plus logique pour elle de la stocker, mais elle n'a pas la capacité de le calculer en interne. En effet, elle a besoin pour ça de image_IR et image_visible qui est dans CFP (c'est pourquoi coeff_mul avait été placé dans CFP).
Elle pourrait utiliser get pour aller chercher ce qu'il faut. Encore faut-il que la classe CFP soit instancié à cet instant? (ordre de création?)

Merci d'avance pour vos commentaires

[Luc Hermitte]

Des classes sans composition ni héritage ne sont pas des abérrations. J'en ai des tonnes des comme ça.

Ne connaissant pas ton problème, j'ai un peu de mal à voir tes histoires de couplages. p.ex. En quoi un numéro de choc est-il pertinent pour construire une caméra ? Pourquoi une caméra est associée à un choc ? Ne vit-elle pas sa propre existance en dehors de tout choc ?
Ne peut-elle pas être synthonisée au dernier moment dans la fonction de Choc qui a besoin de la caméra ?

Pour les constructions. L'idéal, en ce qui me concerne, c'est ton cas 1) (on fait tout dans la liste d'initialisation). Parfois, on n'a pas le choix et des initialisations doivent être retardées.

C'est très bien un objet qui fourni des fonctions réalisant les services dont on n'a besoin. Nul besoin de tout composer. La bétonière n'est pas un élément du maçon. Par contre, elle est là et il peut aller y accéder lorsqu'il en a besoin. Le maçon est sur un chantier où un certains nombre de ressources sont disponibles -- là, on est un peu dans une logique entité.

Dans une logique plus informaticienne, on peut définir une classe de calcul, p.ex un classe qui définit le processus de préparation du béton armé. (On pourrait faire ça avec une fonction, mais une classe peut avoir du sens aussi, surtout si le temps est une donnée externe avec laquelle il faut se synchroniser).
Dans la construceur tu prendras ton ciment, les graviers, l'electricité, le tuyau d'arrosage, le manipulateur,... Cela servira à initialiser des ressources locales à l'algorithme. Ses services vont être de démarrer le processus, de réagir à des événements (rajout d'"ingrédients"), de programmer des événements (timer, observation d'un état "acceptable", ...). Une fois l'état acceptable atteint, on peut aller chercher ce qui a été préparé.

C.-à-d. une classe qui va ponctuellement être instanciée dans une fonction (en fonction du contexte d'exécution) pour réaliser un traitement fonction de ce contexte courant. A la fin de la fonction cliente, plus besoin de l'objet. Il n'y a pas de composition.

Un attribut, tant que ce n'est qu'un attribut (donnée d'implémentation), ce n'est pas choquant de le dupliquer. Le tout est de savoir d'où il vient et comment tu pourras le transmettre aux divers traitements qui en ont besoin.
Enfin. Cela ne me choque pas si l'attribut est avant tout une valeur immuable. Si'il s'agit d'une entité autonnome, cela veut dire que l'on va soit sortir les pointeurs, soit mettre en place des mécanismes complexes de propagation des changements d'état.

[poukill]

Des classes sans composition ni héritage ne sont pas des abérrations. J'en ai des tonnes des comme ça.

Bon d'accord, ça me parait bon comme approche pour moi.

Ne connaissant pas ton problème, j'ai un peu de mal à voir tes histoires de couplages. p.ex. En quoi un numéro de choc est-il pertinent pour construire une caméra ? Pourquoi une caméra est associée à un choc ? Ne vit-elle pas sa propre existance en dehors de tout choc ?

Oui je comprend que ce soit pas facile à comprendre. C'est quand même une machine pas comme les autres que j'ai à gérer... Quelques infos quand même: un "choc", c'est une expérience dans le jargon des physiciens. Ce qu'on étudie ici ce sont les chocs, i.e les expériences réalisées.
Les caméras infrarouges sont toutes en communication avec une base de données centrales. Pour initialiser une caméra, il faut avoir connaissance de tous ces paramètres (température des optiques, transmission etc.), qui varient à chaque expérience. Elle vit donc sa propre existence en dehors de tout choc, mais pour analyser les films qu'elle produit, il faut ce numero de choc!

Ne peut-elle pas être synthonisée au dernier moment dans la fonction de Choc qui a besoin de la caméra ?

Ben je pense que c'est possible. A voir

Pour les constructions. L'idéal, en ce qui me concerne, c'est ton cas 1) (on fait tout dans la liste d'initialisation). Parfois, on n'a pas le choix et des initialisations doivent être retardées.

Dans ma tête, je pensais faire tout d'un coup. Lorsque que dans ma classe choc, je rentre le numero du choc et le nom du composant face au plasma à regarder, tout s'enchaine: initialisation de la camera, capture automatique de la bonne image infrarouge de référénce, chargement des points de controle... Tout ça dans le constructeur...
Peut-être ai-je été un peu gourmand...

C'est très bien un objet qui fourni des fonctions réalisant les services dont on n'a besoin. Nul besoin de tout composer. La bétonière n'est pas un élément du maçon. Par contre, elle est là et il peut aller y accéder lorsqu'il en a besoin. Le maçon est sur un chantier où un certains nombre de ressources sont disponibles -- là, on est un peu dans une logique entité.

Voilà quelque chose qui m'intéresse ENORMEMENT. Ma classe principale (Choc tu l'auras compris) possède plusieurs attributs : Camera, *cfp et numero_choc. Les deux premiers, on peut pas vraiment dire qu'ils sont nécessaires au sens bétonière/maçon. Un choc étant une expérience, il ne "possède" pas une camera...
Le truc c'est que pour un choc donné, on analyse à la fois qu'un seule composant (CFP) via une seule camera (Camera). J'ai cru bon de les regrouper dans choc.
Peut-être vaut-il mieux que je les laisse séparer, et alors que j'utilise une méthode CreationCamera, et NouveauCFP...
Franchement j'en sais trop rien, y'a tellement de possibilités. Des conseils ici seront grandement les bienvenus!

Dans la construceur tu prendras ton ciment, les graviers, l'electricité, le tuyau d'arrosage, le manipulateur,... Cela servira à initialiser des ressources locales à l'algorithme. Ses services vont être de démarrer le processus, de réagir à des événements (rajout d'"ingrédients"), de programmer des événements (timer, observation d'un état "acceptable", ...). Une fois l'état acceptable atteint, on peut aller chercher ce qui a été préparé.

Oui mais comment récupérer les noms des objets? Comment savoir lequel a été déjà été instancié? Le ciment, les graviers, tu les crées dans le constructeur de béton? Tu t'assures qu'ils sont bien créés, sinon tu les créés? Typiquement ce sont des questions génantes pour moi...
Toutefois, je comprend parfaitement l'esprit, et je sens approcher à grand pas de la solution finale...

C.-à-d. une classe qui va ponctuellement être instanciée dans une fonction (en fonction du contexte d'exécution) pour réaliser un traitement fonction de ce contexte courant. A la fin de la fonction cliente, plus besoin de l'objet. Il n'y a pas de composition.

Oui oui, je comprend bien.
Pas de composition, juste un appel occasionnel.

Un attribut, tant que ce n'est qu'un attribut (donnée d'implémentation), ce n'est pas choquant de le dupliquer. Le tout est de savoir d'où il vient et comment tu pourras le transmettre aux divers traitements qui en ont besoin.
Enfin. Cela ne me choque pas si l'attribut est avant tout une valeur immuable. Si'il s'agit d'une entité autonnome, cela veut dire que l'on va soit sortir les pointeurs, soit mettre en place des mécanismes complexes de propagation des changements d'état.

Oui je vois. J'avais déjà pensé aux pointeurs.
Les mécanismes de propagations c'est ce que j'essaye de faire, mais c'est pas évident de faire ça proprement...


Merci encore pour ton aide!

[Matthieu Brucher]

En fait, ce que tu appelles caméra, ce n'est pas une caméra mais le résultat qu'elle a enregistré ?

[poukill]

En effet. Camera joue plusieurs rôles:
1) son initilisation (i.e la lecture de ses paramètres: la température de ses 21 lentilles, etc.)
2) L'importation de films infrarouges sur le serveur.
3) La conversion de niveau de gris en température.

La lecture des paramètres intrinsèques concernent bien la caméra elle-même. pour le reste, c'est ce qu'il y a autour.
J'ai pensé qu'elle ferait bien ce rôle d'importation étant donné que c'est elle qui regarde le film, non?

[Matthieu Brucher]

A priori, ça pourrait convenir. Dans l'avenir, si le programme évolue, tu pourras faire une classe caméra qui charge ses paramètres et qui lit et donc crée une instance d'une classe qui contient les données du film.

[poukill]

Hé oui... Luc et toi êtes globalement du même avis...
Plus de classes "indépendantes" favoriserait à la fois une meilleure compréhension, ainsi qu'une meilleure indépendances entre classes.

Je pourrais effectivement créer une classe Donnees, dont le rôle serait exclusivement d'importer les images infrarouges. ImpotDonnees() n'a besoin que de numero_choc et numero_camera pour aller chercher les données via la Base de Données centrale.

Etant donné que mon diagramme est loin d'être validé, je pense alors partir pour de nouvelles créations de classes, sans interactions entre elles quand celà est possible.

Miles : ton avis sur le fait de créer une classe choc qui ne contiendrait que numero_choc. Ainsi, CFP et Camera seraient autonome?
Pas indispensable du fait que je n'ai à chaque fois q'une seule instance n'est ce pas?

[Matthieu Brucher]

Non, j'ai pas réfléchi aux détails à ce niveau, mais juste au niveau architectural, chaque instance de camera n'a que les paramètres d'une caméra et est utilisé pour créer une instance de Donnees qui serait utilisée apr la suite dans ton expérience. C'est une espèce de Factory, ce n'est pas Donnees qui crée des instances de Donnees, c'est Camera.

[poukill]

Hum. Ce sera donc Camera qui appellera le constructeur de Donnees. Ce qui est parfaitement logique.

Pour le reste, je vais rester comme ça, commencer à placer quelques pions sur mon échiquier, et attendre la réponse de Luc pour terminer les derniers détails!

Merci Miles.

[Luc Hermitte]

un "choc", c'est une expérience dans le jargon des physiciens. Ce qu'on étudie ici ce sont les chocs, i.e les expériences réalisées.
Les caméras infrarouges sont toutes en communication avec une base de données centrales. Pour initialiser une caméra, il faut avoir connaissance de tous ces paramètres (température des optiques, transmission etc.), qui varient à chaque expérience. Elle vit donc sa propre existence en dehors de tout choc, mais pour analyser les films qu'elle produit, il faut ce numero de choc!

Alors le choc correspond à ton contexte d'exécution, ton monde, ton chantier.
Il ne me parait pas anormal que s'y trouvent les capteurs et autres choses observées. Pour définir des contextes/mondes, je vois principalement deux approches :

a- si au cours d'une exécution de ton programme tu n'as qu'un seul contexte géré à la fois. Alors tu peux utiliser une variable globale. Pour faire hype, tu peux la déguiser en singleton personne n'osera plus te dire "c'est tout pourri, tu as une variable globale"

b- si il est possible d'avoir plusieurs contextes actifs simultannéement (ou si tu veux pouvoir faire évoluer facilement ton code initialement mono-contexte) alors il te faut effectivement un lien "retour", explicite, du contenu vers le contenant. C'est le maçon qui sait sur quel chantier il se trouve. Ce lien peut être mis en place de diverses façons :
- un pointeur s'il est possible que l'entité, considérée, change de contexte. Un maçon ou une ressource comme une bétonière peut changer de chantier.
- une référence si l'entité ne migrera jamais. C'est l'option que je privilégie en général. D'après ce que j'ai compris, tes caméras qui sont spécifications de l'observateur + données observées ne migreraient jamais
- un ID (entier, nom, ...) qui sera utilisé dans un gestionnaire de contextes (implémenté comme une variable globale/un singleton) pour obtenir le contexte courant. Cela ressemble beaucoup à la solution pointeur. Je n'ai pas particulièrement de préférence, je fais ça au feeling en général.


Ensuite ces données qui évoluent dans un contexte vont être demandeuses d'un certain nombre d'infos, et autres services, auprès de ce contexte. Une info statique/immuable, on peut envisager de la dupliquer. D'autres, on les demandera directement en passant par des services dédiés "la truelle propre la plus proche() : truelle*", "ID à utiliser pour la BD : ID", ... Le contexte peut aussi s'occuper de réaliser des calculs (qu'il déléguera à des entités contenues).

Là, j'ai déjà croisé deux visions :
- celle où le contexte est saturé d'opérations et des détails sur les fonctionnements de tout le monde
- celle où le contexte n'est qu'un marrieur qui s'occupe de mettre en contact des entités qui savent travailler les unes avec les autres.

J'ai tendance à préférer la seconde approche qui isole mieux les interactions. C'est une approche un peu plus "agent".

Dans ma tête, je pensais faire tout d'un coup. Lorsque que dans ma classe choc, je rentre le numero du choc et le nom du composant face au plasma à regarder, tout s'enchaine: initialisation de la camera, capture automatique de la bonne image infrarouge de référénce, chargement des points de controle... Tout ça dans le constructeur...
Peut-être ai-je été un peu gourmand...

:-/ Possible.
Si ton truc c'est des mesures TR sur un vrai terrain (pas une simulation ou autre), j'aurais tendance à bien décomposer les diverses choses. Chosent qui peuvent se produire en parallèle, mais surtout dans le temps.
La construction s'occupant de la partie informatique (principalement des initialisations de références). Et après, des services qui démarrent les diverses actions qui prennent du temps à se dérouler.
(Cela me rappelle des vieux TDs de RdP(etri)+UML+C++. Je savais que j'aurais dû faire une photocop de mes supports avant de les passer à la relève)

Un choc étant une expérience, il ne "possède" pas une camera...

En fait. Un petit peu. Une expérience est un contexte d'exécution. Et un contexte d'exécution possède des instances (informatiques) de capteurs qui permettent de se connecter aux vrais capteurs utilisés, de retenir leur état courant, ...

Franchement j'en sais trop rien, y'a tellement de possibilités. Des conseils ici seront grandement les bienvenus!

Il y a effectivement énormément de possibilités. Et aucune vérité.

Pour le reste, je vais rester comme ça, commencer à placer quelques pions sur mon échiquier, et attendre la réponse de Luc pour terminer les derniers détails!

Faut être patient avec mes réponses. En espérant qu'elles ne te détournent pas trop de ton chemin.

[poukill]

Je pense commencer par un mono_contexte. C'est le cahier des charges prévu, et beaucoup plus simple (j'avoue ne pas avoir tout saisi sur le multi-contexte!).
L'idée de la variable globale, j'y avais pas pensé. Comme tu l'as si bien dit, elle est si souvent huée que l'hypothèse n'a même pas été envisagée.

Le singleton, c'est très hype! Pourquoi pas? Je vais voir.

En tous cas, je commence à y voir plus clair, et qui sait, je vais peut-être pondre un code propre ?

MERCI !


EDIT: pour l'instant, je vais surement mettre une variable globale...

[poukill]

Une tout petite question:
Avec des variables globales : numero_choc et nom_composant, je ne peux donc pas vérifier que le futur programmeur ne modifie ces champs...
Peut-être alors un singleton fera l'affaire?

[Matthieu Brucher]

Peut-être. Ca dépend de la méthode que tu laisseras accessible par tout le monde et celle qui te donnera la permission de modifier tes valeurs.

[Luc Hermitte]

Et pourquoi ne pas centraliser ces infos dans ton monde (le choc) ?

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
--------------------------------------------
// Camera .h
struct Choc; // déclaration en avant, nécessaire pour les dependances circulaires (FAQ)
 
struct Camera {
    Camera(Choc & c);
...
private:
    Choc      & getChoc()       {return m_choc; }
    Choc const& getChoc() const {return m_choc; }
    int getChocNum() const;
 
    Choc & m_choc; // référence => on ne change pas de contexte!
}
 
--------------------------------------------
// Choc.h
#include "Camera.h"
struct Choc {
    int         getNum() const;
    std::string getComposant() const;
....
private:
    int         m_numero;
    std::string m_composant;
    Camera      m_c1;
};
 
--------------------------------------------
// Camera.cpp
#include "Camera.h"
#include "Choc.h"
 
Camera::Camera(Choc & c) : m_choc(c) { ... }
 
int Camera::getChocNum() const {
    return getChoc().getNum();
}
 
--------------------------------------------
// Choc.cpp
#include "Camera.h"
#include "Choc.h"
 
Choc::Choc(....) : m_c1(*this) { ... }

Si tu veux partir avec un seul choc singleton, tu changes getChoc() pour renvoyer la référence à ce singleton (et tu fais sauter les arguments de construction)

Si tu veux plusieurs chocs, tu laisses comme ça

Si tu veux ces Camera qui migrent, ce n'est plus une référence à choc, mais un pointeur. De même le choc ne contiendra plus une donnée caméra, mais un pointeur sur caméra. Soit un pointeur dont le choc est responsable, soit un pointeur qui appartient à un gestionnaire de caméras. Attention, dans le second cas, à traiter les caméras ponctuellement associées à aucun choc.

[poukill]

Et pourquoi ne pas centraliser ces infos dans ton monde (le choc) ?

C'est une très bonne idée !

Si tu veux partir avec un seul choc singleton, tu changes getChoc() pour renvoyer la référence à ce singleton (et tu fais sauter les arguments de construction)

Si tu veux plusieurs chocs, tu laisses comme ça

Alors tu me poses une colle. Parce que, je pourrai en effet m'intéresser à plusieurs chocs (c'est d'ailleurs le but) succesivement, mais pourquoi pas comparer deux chocs!!! Je sais que les physiciens en ont grandement besoin donc c'est une bonne idée.Donc je pense laisser ça comme ça.

Sinon, pour un même choc, je dois pouvoir changer de caméra (pour regarder un composant différent).

Donc en gros, voilà le cahier des charges:
1) Plusieurs chocs doivent pouvoir être étudiés. Soit chacun leur tour (avec donc une destruction du choc), soit en parallèle (on doit pouvoir gérer cette chose là! )
2) Dans l'étude d'un choc, on doit pouvoir changer de caméra.
L'idéal serait effectivement de pouvoir regarder plusieurs caméras (là aussi pb de mémoire peut-être).

Possibilités d'avoir plusieurs caméras et plusieurs chocs donc!

A l'origine, mon petit programme en C/C++ n'analysait qu'un choc et qu'une caméra. Là on va pouvoir faire mieux !

Donc si j'ai bien compris:
1) il me faut un pointeur vers Camera plutôt.
2)

Si tu veux ces Camera qui migrent

Ben là je sais pas trop ce que tu veux dire... Une caméra est initialisée par rapport à sa propre position, donc suivant l'objet qu'elle regarde. Elle ne possède pas les même paramètres d'un objet à l'autre.
Donc je pense que la réponse est non... pas de migration

Donc une référence à Choc plutôt qu'un pointeur?
Mais si j'ai plusieurs caméras, est-ce qu'elles peuvent toutes contenir une référence au même choc? Ne vaut-il mieux pas un pointeur?
Ce n'est pas vraiment une migration, mais je dois pouvoir en avoir plusieurs, quitte à en détruire une pour en remplacer par une autre...

Soit un pointeur dont le choc est responsable, soit un pointeur qui appartient à un gestionnaire de caméras. Attention, dans le second cas, à traiter les caméras ponctuellement associées à aucun choc.

Waouh... Le second cas me parait un peu prématuré. Celà dit je vais y réfléchir. C'est sans doute une bonne idée. Mais ça fait déjà deux semaines que je suis sur cette conception, j'ai hâte de commencer à coder!

Merci encore en tout cas, ça m'aide vraiment.

Bye

[Luc Hermitte]

Quand je parle de migration de caméra, c'est d'un choc à l'autre que je l'entends.
Un peu comme un individu qui va quitter la population d'une île pour celle d'une autre.

Pour ce genre de choses, l'utilisation de pointeurs est nécessaire. Les références servant à définir des liens qui ne peuvent être rompus.