Discussion :

[bm]

bonjour ,

Je découvre depuis peu les classes de C++ en programmation d'un micro-controleur Arduino . Le but est d'intégrer des parties de C++ dans une bibliothèque . Schématiquement , il y a 2 classes A,B . Je veux ensuite qu'une classe R ( résultat ) prépare des calculs issu des classe A,B .
Mais je ne sais pas rédiger le passage des méthodes :

de A->R
et de B->R

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
 
Fichier lib.h:
class A
{
  public:
  A();
  void function_A1();
  private:
  [liste de variables]
}
 
class B
{
  public:
  B();
  void function_B1();
  private:
  [liste de variables]
}

Et

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Fichier lib.cpp:
A::A()
{//
}//
void A::function_A1()
{ //
}//
A::A()
{//
}//
void B::function_B1()
{ //
}//

Comment rédiger l'utilisation dans une classe R des méthodes de A et B ?
Je veux que function_A1() et function_B1() sont utilisables dans R , sans tout re-écrire . Je vois la possibilité dans R d'empiler , ce que j'écris à la main dans la console .

C'est le dernier étage d'une bibliothèque , qui me permettra de faire tous les mixage possibles issus des classes de cette bibliothèque ..



NB :en uml c'est une agrégation externe de 1 à n dans la classe R .

[koala01]

Salut,

Il est particulièrement difficile de répondre à une telle question hors de tout contexte, car chaque situation est unique.

Par contre, tu devrais te poser un certain nombre de questions qui te mettront sans doute sur la voie de "la moins mauvaise solution" dans ta situation particulière :

• Qui est responsable de l' (ou des) objet(s) de type A
• Qui est responsable de l' (ou des) objet(s) de type B
• Est-ce l'objet de type R qui a besoin d'une information détenue par l'objet de type A (ou par l'objet de type B) ou est-ce au contraire l'objet de type A (ou l'objet de type B) qui devra manipuler une information détenue par l'objet de type R
• Est-ce que l'objet de type R connait l'objet (les objets) de type A ou de type B
• Si ce n'est pas le cas, qu'est ce qui va permettre à l'information de passer
• Est-il seulement cohérent de forcer R à connaitre A et B
• Est-ce R qui doit faire appel "de lui même" au services exposés par A et par B, ou y a-t-il "quelque chose" qui pourra faire le lien entre les deux
• S'il y a "quelque chose" qui fait le lien entre les deux, dans quel sens fait-il ce lien en transmettant l'information de A (ou de B) vers R ou en la transmettant de R vers A (ou vers B)
• J'en passe, et surement de meilleures

La réponse à ta question dépendra énormément de la réponse que tu pourras donner à celles que je pose ici.

Si tu veux une réponse plus précise, commences peut etre par nous donner un contexte plus précis que "je travailles sur une bibliothèque" ou "c'est pour développer sur adurino", car aucune de ces informations n'est réellement pertinente dans le cas présent

[bm]

Je parts de l'existant que je veux optimiser . C'est d'abord du bidouillage avec C++ . J'ai une librairie avec 3 classes ( Base , Arbre , Tete ) qui pilotent des leds .

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
 
#include <Noel.h>
 
Base Anim_0 = Base(0,1,2,3,4,5,6,7,8,9,10,11,12);
Arbre Anim_1 = Arbre(0,1,2,3,4,5);
Tete Anim_2 = Tete(6,11,12);
 
long nb;
 
void setup()
{
randomSeed(analogRead(0));
}
 
void loop ()
{
nb = random(1,4);
Anim_1.anim_a0(nb);
delay(600); 
nb = random(1,9);
Anim_2.anim_t0(nb);
delay(600); 
Anim_0.anim_b0(13);
delay(600); 
}

Je veux que une classe de plus "Final" fasse le calcul de void loop()
Ce qui donnera :

Code :

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

1
2
3
4
5
6
7
 
Final Fin = Final(1);
void loop ()
{
Fin();
delay(600); 
}

La conception n'est pas évolutive . Et je ne sais pas si une librairie peut fonctionner avec un fichier .h et plusieurs fichiers .cpp

[koala01]

La conception n'est pas évolutive . Et je ne sais pas si une librairie peut fonctionner avec un fichier .h et plusieurs fichiers .cpp

Et je présumes que tu voudrais être en mesure d'ajouter d'autres classes (Pere_Noel, Boule, Traineau ou autre ) par la suite

Hé bien, je vais répondre aux questions pour toi, vu que tu n'as pas fait l'effort de le faire toi-même ici

Qui est responsable de l' (ou des) objet(s) de type A

L'objet R, indiscutablement

Qui est responsable de l' (ou des) objet(s) de type B

L'objet R, indiscutablement

Est-ce l'objet de type R qui a besoin d'une information détenue par l'objet de type A (ou par l'objet de type B) ou est-ce au contraire l'objet de type A (ou l'objet de type B) qui devra manipuler une information détenue par l'objet de type R

Ni l'un ni l'autre... Voir plus loin

Est-ce que l'objet de type R connait l'objet (les objets) de type A ou de type B

Oui, et bien d'autres encore (à déterminer au fur et à mesure)

Si ce n'est pas le cas, qu'est ce qui va permettre à l'information de passer

Pas d'actualité

Est-il seulement cohérent de forcer R à connaitre A et B

Sans doute, mais peut être pas comme étant A et B

Est-ce R qui doit faire appel "de lui même" au services exposés par A et par B, ou y a-t-il "quelque chose" qui pourra faire le lien entre les deux

C'est l'objet R qui fait directement appel à un service de A et de B, mais dans une boucle sans doute

S'il y a "quelque chose" qui fait le lien entre les deux, dans quel sens fait-il ce lien en transmettant l'information de A (ou de B) vers R ou en la transmettant de R vers A (ou vers B)

pas d'actualité.

Ce que je vais te proposer, c'est d'utiliser l'héritage, le polymorphisme d'inclusion et un idiôme connu sous le nom de "clonable".

L'idée est de se dire que Base, Arbre et Tête -- sans oublier toutes les classes qui pourraient venir par la suite -- sont tous des Animations, au sens strict (comprends : au sens sémantique, tel qu'on le trouve dans le dictionnaire) du terme.

Ce sont donc des candidats idéaux pour intervenir dans une hiérarchie de classes dont une classe Animation serait la classe mère et dont toutes les autres seraient des classes filles.

En conception orientée objets, il faut veiller à respecter cinq piliers connus sous l'acronyme SOLID, dont le L est mis pour LSP (Liskov Substitution Principle, ou, si tu préfères, le Principe de Substitution de Liskov).

Ce dernier nous dit

Soit q(x) est une propriété prouvable à propos des objets x de type T. Alors q(y) doit être vrai pour les objets y de type S lorsque S est un sous-type de T.

Si l'on considère que la classe Animation est le type T, toutes les classes (Base, Arbre, Tête et toutes les autres à venir) peuvent être considérées comme étant le type S si (et seulement si) toute propriété prouvable à propos de T (de Animation, si tu préfères) et une propriété prouvée de S (Base, Arbre, Tete, ...).

Faisons simple (car c'est en réalité un peu plus complexe que cela) : en programmation OO, toute fonction membre publique peut forcément être considérée comme une propriété prouvable qui s'énoncerait sous la forme de "expose un service qui permet de (faire quelque chose de bien précis)".

Il y aura, a priori, deux fonctions membres publiques (en plus du destructeur, qui doit être virtuel) au niveau de Animation que l'on devra donc forcément retrouver au niveau des classes dérivées:

La première, c'est celle qui permettra d'afficher l'animation en allumant et en éteignant tes leds dans un ordre bien particulier.

Nous allons la nommer run(), par exemple, mais tu peux choisir un nom différent (comme execute(), show, ou ce que tu veux). Cette fonction sera bel et bien une propriété prouvable des sous types (comprends : des types dérivés) si elle permet -- en adaptant le comportement de la fonction au besoin -- à chaque sous type d'allumer et d'éteindre les leds dans un ordre particulier.

La deuxième fonction libre intervient dans l'idiome "clonable" dont je t'ai parlé : Il s'agit de fournir une fonction libre clone() qui permet de renvoyer un pointeur vers un objet connu comme étant du type de base (autrement dit un Animation * dans le cas qui nous intéresse) qui pointe vers un tout nouvel objet de type dérivé (Arbre, Tete, Base, ou toutes les autres) pour lequel nous avons eu recours à l'allocation dynamique de la mémoire.

Là aussi, au prix d'une adaptation du comportement de cette fonction clone(), nous pouvons dire que cette propriété prouvable qui consiste à renvoyer un pointeur de type Animation au niveau de la classe Animation est bel et bien une propriété prouvable au niveau des classes dérivées.

Et comme je présumes que c'est ce que tu veux faire, nous sommes dans une situation dans laquelle LSP est respecté. Nous pouvons donc effectivement faire appel à l'héritage public entre Animation et ( Arbre, Base, Tete et toutes les autres ).

Nous pouvons donc envisager d'avoir une hiérarchie de classes proche de

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
class Animation{
    public:
        Animation(Animation const &) = delete; // C++11 inside (*)
        Animation & operator=(Animation const &) = delete; // C++11 inside (*)
        virtual ~Animation();
        virtual void run(long )  = 0; // en attente de définition du comportement réel
        virtual Animation * clone() const = 0; // en attente de définition du comportement réel
};
class Base : public Animation{
    public:
        virtual void run(long ); // A définir pour Base
        virtual Animation * clone() const;
 
};
class Tete: public Animation{
    public:
        virtual void run(long ); // A définir pour Base
        virtual Animation * clone() const;
 
};
class Arbre : public Animation{
    public:
        virtual void run(long ); // A définir pour Base
        virtual Animation * clone() const;
 
};

La fonction run dépendra de la manière dont chaque classe veut provoquer l'affichage. Il t'appartiendra donc de veiller à fournir un comportement cohérent pour cette fonction.

Le destructeur de la classe Animation sera tout simple car il ne fait strictement rien. Il prendra donc la forme de

Code :

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

1
2
3
Animation::~Animation(){
 
}

Enfin, la fonction clone s'adaptera pour renvoyer un objet (créé avec new) du type correspondant au type réel de l'objet au départ duquel elle est appelée. Elle prendra donc les formes de

Code :

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

1
2
3
4
5
6
7
8
9
10
Animation * Base::clone() const{
    return new Base;
}
Animation * Arbre::clone() const{
    return new Arbre;
}
Animation * Tete::clone() const{
    return new Arbre;
}
/* et ainsi de suite pour toutes les autres classes */

(*) Cela permet d'éviter la copie et / ou l'affectation des objets du type de la classe de base et / ou de ses types dérivés. C'est normal dans le sens où les types intervenant dans une hiérarchie de classes ont sémantique d'entité et que le fait de n'être ni copiable ni affectable est une des caractéristiques majeures des classes ayant sémantique d'entité

Si tu ne disposes pas de la possibilité d'utiliser c++11, tu peux déclarer le !!!SANS LES DEFINIR!!! constructeur par copie et l'opérateur d'affectation de la classe de base dans l'accessibilité privée

A partir du moment où l'on a cela, le plus dur est fait...

Car, l'idée est de créer une classe qui va, tout simplement, disposer d'un tableau de pointeurs (intelligents, de préférence) vers la classe Animation ainsi que de deux fonctions:

La première sera nommée (par exemple) registerItem et prendra une référence constante vers un objet de (connu pour être du) type Animation et aura pour résultat d'ajouter au tableau en question un nouvel objet identique à celui reçus sous la forme de référence (grâce à la fonction clone), la deuxième, qui pourrait être nommée execute(), run() ou tout autre non équivalent, s'occupera de parcourir chaque élément du tableau afin d'invoquer la fonction run (ou tout autre nom que tu auras choisi à la place) au départ de l'objet en question.

Elle ressemblerait donc à quelque chose comme

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
// !!!!   C++11 inside (**)
class AnimationLibrary{
    public:
        void registerItem(Animation const & toadd){
            items_.emplace_back(std::unique_ptr<Animation>(toadd.clone());
        }
        void execute(){
            for (auto & it : items_){
                long nb = random(1,4);
                it.get()->run(nb);
                delay(600); 
            }
        }
    private:
        std::vector<std::unique_ptr<Animation>> items_;
};

(**)Si tu ne disposes pas de la possibilité d'utiliser C++11, elle prendra plutôt la forme de

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
class AnimationLibrary{
    public:
        ~AnimationLibrary(){
            for (size_t index=0; index < items_.size();++index){
                delete items_[index];
            }
        }
        void registerItem(Animation const & toadd){
            items_.push_back(toadd.clone());
        }
        void execute(){
            for (size_t index=0; index < items_.size();++index){
                long nb = random(1,4);
                items_[index]->run(nb);
                delay(600); 
            }
        }
    private:
        // évitons la copie et l'affectation (par facilité ;)) 
        AnimationLibrary(AnimationLibrary const &); //A NE PAS DEFINIR
        AnimationLibrary & operator = (AnimationLibrary const &); //A NE PAS DEFINIR
        std::vector<std::unique_ptr<Animation>> items_;
};

Il me reste un dernier point à aborder pour être complet:

De toute évidence, les valeurs que tu introduis dans les constructeurs de tes classes sont les numéros de leds utilisées.

A priori, chaque doit donc savoir quelles leds elle peut utiliser et comment les utiliser dans quel ordre, mais ces leds dépendent de l'animation que tu veux leur faire jouer.

Dés lors, pourquoi veux tu obliger l'utilisateur de la classe à indiquer lui-même les leds que les différents objets doivent utiliser

Ne serait il pas préférable de les indiquer "par défaut", histoire que l'utilisateur n'ait même pas à s'inquiéter de cet aspect des choses

Plutot que d'avoir un constructeur de Tete qui ressemble à

Code :

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

1
2
3
Tete::Tete(int, int, int) : /* ... */{
    // ..
}

Pourquoi ne pas avoir un constructeur de Tete qui ressemble à

Code :

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

1
2
3
Tete::Tete(){
    // tu sais qu'il utilise d'office les leds 6, 11 et 12
}

au final, ta fonction main pourrait ressembler à

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int main(){
    AnimationLibrary lib;
    lib.registerItem(Base());
    lib.registerItem(Arbre());
    lib.registerItem(Tete());
    bool finished = false;
    /* et tous les autres */
    while(! finished){
        lib.execute();
    }
}

Et je ne sais pas si une librairie peut fonctionner avec un fichier .h et plusieurs fichiers .cpp

On va faire simple :

Tant que tu veilles à ne définir qu'une fois chaque fonction ou chaque fonction membre, tu peux définir n'importe quelle fonction dans n'importe quel fichier *.cpp, à une (et une seule) condition : le compilateur doit connaitre tout ce que la fonction utilise.

tu peux donc également séparer la déclaration de tes fonctions libres et la définition de tes classes en autant de fichiers d'en-tête que tu le souhaites, mais, si tu définis une fonction qui utilise la fonction foo() ou la classe MaClasse, tu dois vieller à ce que le fichier dans lequel tu défini ta fonction inclue bien (au travers de la directive #include <nom du fichier> ) le fichier dans lequel la fonction foo() est déclarée et/ou celui dans lequel la classe MaClasse est définie

[bm]

Merci , pour ce développement . J'ai effectivement commencé à me documer sur l'héritage multiple . Hériter pour construire des objets différents ( cercle -> sphere ou ->cone ) est l'exercice de base pour comprendre l'héritage .

Vu que le support de l'animation de leds est différentes fonctions ( les classes définissent des regroupement de leds sous forme de motifs fixes ) :

Une animation hérite des fonctions d'une classe et je peux construire une fonction finale par animation . Les animations sont indépendantes et sans héritage l'une par rapport à l'autre .

Je peux indexer les classes et fonctions ( animations ) par fichiers .h et .cpp , ce qui donnera :

noel_1.h
noel_1.cpp

noel_i.h
noel_i.cpp

... etc pour i de 1 à n animations

Difficile ensuite de savoir à partir de combien de fichier , le compilateur de Arduino va saturer . Rien que avec 3 classes ( Base , Arbre , Tete ) , j'ai déjà indexé les chaines de
variables pour ne pas écrire des doublons .

Quelles sont les commandes console du c++ , pour sortir des info sur les capacités
de compilation du compilateur Arduino ?

Cordialement
--------------------------------
Est ce faisable de regrouper des instances de classe dans une fonction
qui n'appartiendra pas à une classe "final" ?

Dans un .cpp avec une fonction final1() . Comment passer ? :
l'objet Anim_1 de la classe Arbre
l'objet Anim_2 de la classe Tete
l'objet Anim_0 de la classe Base

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
void final1(int nb)
{
nb = random(1,4);
//Anim_1.anim_a0(nb);
delay(600); 
nb = random(1,9);
//Anim_2.anim_t0(nb);
delay(600); 
//Anim_0.anim_b0(13);
delay(600); 
}

Avec void final1 sous la forme d'un patron de fonction qui cumulera les 3 instances de classe :

Anim_1.anim_a0(nb)
Anim_2.anim_t0(nb)
Anim_0.anim_b0(13)

C'est ce point de passage des objets dans une fonction finale qui condensera l'anim 1 sur une ligne avec :

Code :

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

1
2
3
4
5
6
7
8
9
 
void loop ()
{
final1(nb); // anim 1 issu du noel1.h et du noel1.cpp
delay(600); 
//la suite logique
//final2(nb); // anim 2 issu du noel2.h et du noel2.cpp
//delay(600); 
}

MAIS JE NE SAIS PAS RÉDIGER CE PATRON DE FONCTION
UN PEU D'AIDE SERA UN PLUS NON NÉGLIGEABLE ...
----------------------
Le compilateur supporte l'empilement de 2 animations , avec une indexation basique des classes et fonctions ( les variables internes sont les mêmes )
Je passe le sujet en résolu .
Code final :

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
 
#include <Noel1.h>
#include <Noel2.h>
 
Base1 Anim_10 = Base1(0,1,2,3,4,5,6,7,8,9,10,11,12);
Arbre1 Anim_11 = Arbre1(0,1,2,3,4,5);
Tete1 Anim_12 = Tete1(6,11,12);
 
Base2 Anim_20 = Base2(0,1,2,3,4,5,6,7,8,9,10,11,12);
Arbre2 Anim_21 = Arbre2(0,1,2,3,4,5);
Tete2 Anim_22 = Tete2(6,11,12);
 
long nb;
 
void setup()
{
randomSeed(analogRead(0));
}
 
void loop ()
{
// --- ANIMATION 1 --- //
nb = random(1,4);
Anim_11.anim_a01(nb);
delay(600); 
nb = random(1,9);
Anim_12.anim_t01(nb);
delay(600); 
Anim_10.anim_b01(13);
delay(600); 
// --- ANIMATION 2 --- //
nb = random(1,4);
Anim_21.anim_a02(nb);
delay(600); 
nb = random(1,9);
Anim_22.anim_t02(nb);
delay(600); 
Anim_20.anim_b02(13);
delay(600); 
}

Mon objectif est de 3 animations , ce que je pensais irréalisable avec 50 lignes dans l'EDI Arduino .