je suis bloquée !, c'est du C++

[alocmoa]

Bonjour,

j'ai un sujet qui m'est parvenu récemment et je suis bloquée non pas en programmation mais au tout début c'est à dire au niveau de la réflexion et de la création des classes sur "papier"...

On veut écrire une application pour gérer les factures émises par une société. Chaque facture émise comporte : un numéro de facture (entier), un numéro de client (entier), un descriptif (chaîne de caractères) et un montant total (réel).
L'application devra permettre d’ajouter une facture en précisant ses caractéristiques, d’afficher les caractéristiques d’une facture, d’afficher la liste complète des factures (et le montant total) et d’afficher la liste des factures correspondant à un client donné à partir de son numéro.
Pour mémoriser toutes les factures, l’application utilisera les deux classes Facture et ListeFactures. La classe ListeFactures sera munie des méthodes suivantes :
· AjouterFacture qui permet d'ajouter une nouvelle facture en précisant le numéro du client, le descriptif et le montant (le numéro de facture sera fixé automatiquement comme étant égal au nombre de factures courant),
· AfficherFactures qui permet d'afficher à l'écran la liste toutes les factures émises.
· MontantTotal qui permet de calculer le montant total de toutes les factures.

On m'indique les méthodes à créer dans la classe LIstesFactures et la classe Facture... là je suis perdue... j'ai tourné et retourné le sujet je n'arrive pas à quelquechose de complet et concis. J'ai bien des idées : une méthode RemplirListeFactureClient, un constructeur Facture et un eventuel AfficherFactures mais cela ne me semble pas tout à fait correct... et puis laquelle des deux classes sera la classe mère ????

Si quelqu'un a une idée, je m'intéresserai à la proposition.

En attendant je continue à me pencher sur le problème...

Merci par avance !

Alocmoa

[satan87]

salut

je ne suis pas un pro en classe mais voila ce que je pense

la classe facture correspond a une facture
cad numero, client, montant

la classe liste_facture
correspond a un tableau de facture

la methode ajouter afcture
permet d'ajouter une lement au tableau
et fait appel au construteur de facture


la methode affciher facture
parcours le tablau et appel une methops affciher de la classe afcture

la methode calculer montant
fait la somme pour le trableau de la methode get montant
de chaque facture

a mon avis c'est assez basique, faut pas aller chercher trop loin

[alocmoa]

Merci, plus ca va et plus ca devient clair...

@++ !!!!

[schlum]

Attention avec une liste ... Le problème c'est que c'est à dimension finie ... Donc je suggère soit d'utiliser une liste chaînée, soit une liste de pointeurs sur Facture avec des realloc ...

[Driden]

Si tu fais du C++, utilises les conteneurs de la STL.

[No6]

Salut,
Pour moi, c'et toujours la structure des données qui commande.
tu as 2 classes de base:
une pour les clients
une autre pour les factures.
qu'importe la façon dont les données sont stockées, en SGBD, en pile, en séquentiel indexé, cela n'est pas le pb.
Ensuite tu peux avoir des surClasses comme "Liste Facture" qui se serviront des 2 classes de bases.

Au passage, les méthodes Affichier_Facture et Montant_Total peuvent avoir en argument optionnel le N° de Client.

vala, si ça peut t'aider, faut essayer d'être simple

Ce message a été modifié par No6 - 11 Aug 2004, 14:18.

[schlum]

Voilà un exemple qui marche, mais assez peu optimisé (les listes chaînées c'est assez lourd parfois ...)

CODE

#include <iostream.h>
#include <string.h>

class Facture {
private:
 int num_facture;
 int num_client;
 char *descriptif;
 float montant;

public:
 Facture(int nf,int nc,char *d,float m) {
   num_facture = nf;
   num_client = nc;
   descriptif = new char[strlen(d)+1];
   strcpy(descriptif,d);
   montant = m;
 }

 ~Facture() {
   delete descriptif;
 }

 void afficher() {
   cout<<"\n\nFacture numéro "<<num_facture<<" : "<<descriptif<<"\n";
   cout<<"Numéro du client : "<<num_client<<'\n';
   cout<<"Montant : "<<montant<<'\n';
 }

};

struct listechain {
 Facture *fact;
 struct listechain *suiv;
};

class ListeFactures {
private:
 listechain *deb;
 listechain *fin;
 int num;
 float tot;
public:
 ListeFactures() {
   deb = fin = NULL;
   num = 0;
 }

 ~ListeFactures() {
   listechain *tmp;
   for(listechain *pt = deb;pt;) {
tmp = pt->suiv;
     delete pt->fact;
     delete pt;
     pt = tmp;
   }
 }

 void AjouterFacture(int nc,char *d,float m) {
   Facture *f = new Facture(++num,nc,d,m);
   listechain *l = new listechain;
   l->fact = f;
   l->suiv = NULL;
   if(!fin)
     fin = deb = l;
   else {
     fin->suiv = l;
     fin = l;
   }
   tot += m;
 }

 void AfficherFactures() {
   for(listechain *pt = deb;pt;pt=pt->suiv)
     pt->fact->afficher();
 }

float MontantTotal() {
   return tot;
 }

};

int main() {
 ListeFactures l;
 l.AjouterFacture(12,"Test de facture",10.125);
 l.AjouterFacture(78,"Deuxième facture",76.3);
 l.AjouterFacture(32,"Encore un essai",5.4);
 l.AfficherFactures();
 cout<<"\n\n\nTotal : "<<l.MontantTotal()<<'\n';
 return 0;
}

[Driden]

Les listes chainés c'est bien en C en C++ tu as les arrays pour ça.

[kakace]

En C++, il y a surtout plein de trucs qui prennent du temps pour ne rien faire, ou si peu. Dans le genre "tuer une mouche avec un char d'assaut", on fait difficilement mieux.
J'exècre la STL rien que pour ça.

[alocmoa]

Merci Schlum pour le bout de code ... ca va me débloquer pas mal dejà ...

Ca va déjà mieux ...

Un sincère merci pour l'aide !

Je v regarder le code et le tester...

[schlum]

Les listes chainés c'est bien en C en C++ tu as les arrays pour ça.
[right][snapback]806397[/snapback][/right]

Jamais utilisé ... Je trouve ça assez inutile toutes ces grosses librairies ; autant faire du C, puis passer au Java et / ou Objective-C en sautant l'étape C++ (que j'ai appris mais jamais aimé et utilisé régulièrement en fait )

[dulrich]

moi la même chose... j'ai fais du C .... et un peu e C++... mais je voispas trop l'utilité de ce dernier. Pour l'objet c'est Obj-C ou java.

[Driden]

Les listes chainés c'est bien en C en C++ tu as les arrays pour ça.
[right][snapback]806397[/snapback][/right]

Jamais utilisé ... Je trouve ça assez inutile toutes ces grosses librairies ; autant faire du C, puis passer au Java et / ou Objective-C en sautant l'étape C++ (que j'ai appris mais jamais aimé et utilisé régulièrement en fait )
[right][snapback]806634[/snapback][/right]

Ouais mais le C++ c'est pas du C, faut arreter de vouloir tout mélanger apres on se retrouve avec du n'importe quoi (je dis pas ça pour toi).

[schlum]

Les listes chainés c'est bien en C en C++ tu as les arrays pour ça.
[right][snapback]806397[/snapback][/right]

Jamais utilisé ... Je trouve ça assez inutile toutes ces grosses librairies ; autant faire du C, puis passer au Java et / ou Objective-C en sautant l'étape C++ (que j'ai appris mais jamais aimé et utilisé régulièrement en fait )
[right][snapback]806634[/snapback][/right]

Ouais mais le C++ c'est pas du C, faut arreter de vouloir tout mélanger apres on se retrouve avec du n'importe quoi (je dis pas ça pour toi).
[right][snapback]806640[/snapback][/right]

Sisi, ça me correspond tout à fait En fait, je fais pas de C++, je fais du C avec des classes et quelques cin, cout de temps en temps

[Driden]

Sisi, ça me correspond tout à fait  En fait, je fais pas de C++, je fais du C avec des classes et quelques cin, cout de temps en temps 
[right][snapback]806643[/snapback][/right]

Le carnage
Mais je te rejoinds, je prefere de loin le Java pour de la POO.

[chombier]

moi la même chose... j'ai fais du C .... et un peu e C++... mais je voispas trop l'utilité de ce dernier. Pour l'objet c'est Obj-C ou java.[right][snapback]806639[/snapback][/right]

PowerPlant de MetroWerks, du temps du MacOS Classique, était la seule réelle architecture de classes qui collait parfaitement à la Toolbox du Macintosh, et faisait un large usage de l'héritage multiple, qui n'existe pas en ObjC (oublions Java pour les perfs). Le C++, comme tout langage, a ses adeptes et ses contradicteurs.
De là à dire qu'il n'a aucune utilité...

[ycarry]

[précautions oratoires] si je gêne, je sors tout de suite, je veux pas m'immiscer dans le cercle des programmeurs [/précautions oratoires] .

Dans le genre "tuer une mouche avec un char d'assaut", on fait difficilement mieux.

Pour un application de ce type, pourquoi ne pas utiliser 4D ou FileMaker (ou plus simple même) ? C'est une simple lecture/écriture d'une base de données 'factures'…
dans le cas qui est décrit, pourquoi utiliser le C ?

Criez pas, je suis déjà plus là

[schlum]

[précautions oratoires] si je gêne, je sors tout de suite, je veux pas m'immiscer dans le cercle des programmeurs [/précautions oratoires]  .

Dans le genre "tuer une mouche avec un char d'assaut", on fait difficilement mieux.

Pour un application de ce type, pourquoi ne pas utiliser 4D ou FileMaker (ou plus simple même) ? C'est une simple lecture/écriture d'une base de données 'factures'…
dans le cas qui est décrit, pourquoi utiliser le C ?

Criez pas, je suis déjà plus là
[right][snapback]806932[/snapback][/right]

Et pourquoi pas en excel aussi tant qu'on y est

[schlum]

moi la même chose... j'ai fais du C .... et un peu e C++... mais je voispas trop l'utilité de ce dernier. Pour l'objet c'est Obj-C ou java.[right][snapback]806639[/snapback][/right]

PowerPlant de MetroWerks, du temps du MacOS Classique, était la seule réelle architecture de classes qui collait parfaitement à la Toolbox du Macintosh, et faisait un large usage de l'héritage multiple, qui n'existe pas en ObjC (oublions Java pour les perfs). Le C++, comme tout langage, a ses adeptes et ses contradicteurs.
De là à dire qu'il n'a aucune utilité...
[right][snapback]806822[/snapback][/right]

C'est pas vraiment qu'il n'a aucune utilité ... Plutôt qu'il n'apporte pas grand chose par rapport au C ... Pour les classes, c'est un peu touffu (est-ce qu'il existe une API claire quelque-part ? ) et le fait de garder la compatibilité du C empêche un peu la gestion des objets d'être simple et pratique.

[Driden]

Et pourquoi pas en excel aussi tant qu'on y est 
[right][snapback]806949[/snapback][/right]

Tu sors

[chombier]

C'est pas vraiment qu'il n'a aucune utilité ... Plutôt qu'il n'apporte pas grand chose par rapport au C ... Pour les classes, c'est un peu touffu (est-ce qu'il existe une API claire quelque-part ?  ) et le fait de garder la compatibilité du C empêche un peu la gestion des objets d'être simple et pratique.[right][snapback]806958[/snapback][/right]

Un bête exemple de ce qu'apporte l'héritage multiple: les classes broadcaster et listener.

Une fois que tu comprends comment un langage orienté objet comme le C++ fonctionne, tu peux faire de même dans ta tête et pondre du code procédural quasi-identique en C, malheureusement surtout si tu maîtrises déjà le C. Mais l'inverse est impossible, et c'est bien le C++ qui t'aura appris à mieux coder.

STL est lourd, je suis tout à fait d'accord, mais ce n'est qu'une librairie. Le langage lui-même est extrêment performant.

[schlum]

C'est pas vraiment qu'il n'a aucune utilité ... Plutôt qu'il n'apporte pas grand chose par rapport au C ... Pour les classes, c'est un peu touffu (est-ce qu'il existe une API claire quelque-part ?  ) et le fait de garder la compatibilité du C empêche un peu la gestion des objets d'être simple et pratique.[right][snapback]806958[/snapback][/right]

Un bête exemple de ce qu'apporte l'héritage multiple: les classes broadcaster et listener.

Une fois que tu comprends comment un langage orienté objet comme le C++ fonctionne, tu peux faire de même dans ta tête et pondre du code procédural quasi-identique en C, malheureusement surtout si tu maîtrises déjà le C. Mais l'inverse est impossible, et c'est bien le C++ qui t'aura appris à mieux coder.

STL est lourd, je suis tout à fait d'accord, mais ce n'est qu'une librairie. Le langage lui-même est extrêment performant.
[right][snapback]806975[/snapback][/right]

Pour bien comprendre l'objet, il paraît qu'il faut commencer par un vrai langage objet genre Eiffel ou SmallTalk

[deselegies]

Pour bien comprendre l'objet, il paraît qu'il faut commencer par un vrai langage objet genre Eiffel ou SmallTalk 

De toute facon, en C ou en C++ il y a toujours possibilite de coder comme un Porc.
Je ne pense pas que SmallTalk ou Eiffel apporte plus de protection , le Gros Gruik trouvera toujours sa voie.
Pour ma part je pense que pour bien comprendre l'objet, il faut juste regarder le monde de tous les jours et raisonner en "boite noire" qui rend des services.
Le Langage importe peu en fait, java, c++, ou objective C, le plus important est la bonne comprehension des mechanismes de base et une surtout bonne Conception.
Des methodes existent pour nous aider dans nos tache quotidiennes mais malheureusement les outils ne sont pas dispo sur notre plate-forme.
XCode integrera un outils de modelisation mais est-ce que ce sera juste de la visualisation ou bien permettra t'il la conception ? mystere et boule de gomme.

Je reve d'un Rational Rose sur Mac ...

JC

[apprenti bidouil...]

XCode integrera un outils de modelisation mais est-ce que ce sera juste de la visualisation ou bien permettra t'il la conception ? mystere et boule de gomme.

uniquement visualisation

[deselegies]

uniquement visualisation
[right][snapback]807174[/snapback][/right]

Ouinnnnnnnnnn, Snif comment pourrir une journee.

Bon allez on va dire que c'est la premiere version et que par la suite on pourra modeliser avec XCode.

Hein dit Steve, un petit effort.

Bon j'irais voir au Stand Apple pour faire du lobbying.
Si jamais on avait un soft de modelisation potable sur Mac, on pourrait assister a du Switch de grande envergure pour les projets de developement Java.

JC

[Bac's]

Bon, il faudrait qu'allocmoa nous dise quel est le but de son application.

Si c'est juste un travail scolaire, je ne vois aucun souci à implémenter sa classe LIstesFactures avec les méthodes qu'elle a décrites en utilisant un conteneur de la STL. Elle montrera ainsi qu'elle n'a pas ré-inventé l'eau chaude et qu'elle a bien masqué l'implémentation interne (on ne déroge pas ainsi au principe d'encapsulation).

Si c'est une application qui n'a pas de trop grosses contraintes de performances, on peut aussi utiliser la STL. Le jour où il faudra optimiser, on pourra toujours remplacer le conteneur interne par autre chose.

[SuperCed]

Je suis un peu comme Schlum et Dulrich, j'aime bien le C, java, ou ObjectiveC, mais pas trop le C++.

Je n'aime pas l'héritage multiples, surtout au moment des free... En fait, il faut faire du reference counting, comme en ObjectiveC, sauf qu'en C++, on doit implémenter son propre système de reference counting en tenant compte du fait que le code peut-être multithread par la suite. Donc ça implique des locks et ça complique encore. En ObjectiveC, tout est déjà fait. Java, c'est encore mieux, on laisse tout trainer en mémoire et on laisse faire l'interpréteur.
Voilà pourquoi j'aime pas l'héritage multiple.

Après, en C++, j'aime pas les templates, je trouve que le code est facilement illisible et complexe. Aie, yaura bientôt la possibilité de faire ça en Java...

En C++, j'aime pas la surcharge d'opérateur, c'est l'embrouille totale, et pareil, c'est parfois difficile à lire.

En C++, j'aime bien le principe d'héritage comme en Java ou ObjectiveC d'ailleurs. C'est la seule chose que j'apprécie vraiment en langage objet, le fait de dériver d'autres classes, et d'implémenter quelques méthodes, c'est très pratique pour les interface graphiques par exemple.

J'aime bien utiliser les listes chaînées en C, et controller exactement mes allocations, allouer directement des octets sans passer par des niveau d'abstraction qui rendent parfois abscon le principe du projet.

[alocmoa]

Bonjour ,

Oui, mon sujet est un "travail scolaire"... je delandais juste qq idées et pas me faire mon sujet ....

Je vous remercie tous pour l'aide que vous m'avez donné.

@++

Alocmoa

[chombier]

Je suis un peu comme Schlum et Dulrich, j'aime bien le C, java, ou ObjectiveC, mais pas trop le C++.

Je n'aime pas l'héritage multiples, surtout au moment des free... En fait, il faut faire du reference counting, comme en ObjectiveC, sauf qu'en C++, on doit implémenter son propre système de reference counting en tenant compte du fait que le code peut-être multithread par la suite. Donc ça implique des locks et ça complique encore. En ObjectiveC, tout est déjà fait. Java, c'est encore mieux, on laisse tout trainer en mémoire et on laisse faire l'interpréteur.
Voilà pourquoi j'aime pas l'héritage multiple.

j'ai bouffé du C++ pendant 10 ans, héritage multiple compris, et je n'ai jamais fait de 'reference counting' !? c'est quoi ça ? Tu ne confonds pas avec l'ObjC et son garbage collector ?

Après, en C++, j'aime pas les templates, je trouve que le code est facilement illisible et complexe. Aie, yaura bientôt la possibilité de faire ça en Java...

Là encore, c'est une histoire de goût. Les Templates, c'est un niveau d'abstraction supplémenatire par rapport aux classes virtuelles pures. J'adoore.

En C++, j'aime pas la surcharge d'opérateur, c'est l'embrouille totale, et pareil, c'est parfois difficile à lire.

C'est le propre des langages objets. Si lorsque tu crées une nouvelle classe, tu ne peux l'additionner par '+', ce n'est pas un langage objet.

[alocmoa]

Bonjour !

Bon, j'ai fait tout mon alog, tout fonctionne avec une programme de test sauf une chose.... j'ai une methode qui ne passe pas mais qui à la compilation ne me fait aucune erreur..... avec le programme de test j'ai un "iterateur invalide".... j'ai beau chercher.... je vois pas le souci...

Je peux fournir mes codes sources, à la limite si ca vous dit de jeter un oeil, demandez les moi par mail ...

Merci bcp!

Alocmoa