Discussion :

[Mozofeuk]

Bonjour � tous,

J'ai eu une petite discussion avec des coll�gues et j'aimerais avoir votre avis. Ils (mes coll�gues) r�alisent une application en C++ qui tape dans une base de donn�es SQLite.

Pour des raisons de simplifications me disent-ils, ils ont pr�f�r�s utiliser des structures plut�t que des classes pour repr�senter les objets de la base.

Une table Personne --> Une structure Personne
Une table Produit --> Une structure Produit
Une table ....

Pour moi il est dommage pour un langage objet de ne pas utiliser les classes ainsi que tout les m�canismes qui font la force du langage orient� objet.

Mais leurs arguments sont les suivants, en C++ on peut h�riter d'une structure. Une structure est plus simple � cr�er qu'une classe (disons plus rapide, pas de constructeurs etcetc..). Et une structure peut remplir tous les r�les que peut remplir une classe. Donc comme c'est plus simple et plus rapide ils utilisent des structures...

Pour moi, dans une structure toutes les propri�t�s sont public ce qui implique des probl�me pour la conception. On m'a tout le temps appris � utiliser des propri�t�s priv�s et � y acc�der � l'aide de getter and setter. De plus je suis sur qu'une classe apporte bien plus d'avantage que la propret� du code mais je ne vois pas trop quoi

Personnes n'�tant vraiment sur des arguments que nous avan�ons, j'aurais voulu votre avis sur la question. Qu'elle est la diff�rences entre une structure et une classe (avantages/inconv�nients) ?
Est - il vraiment n�cessaire d'utiliser une classe comme je le pr�conise ?
Peut-il y avoir des diff�rence de performance entre une appli qui utilise structures/classes ?

Merci pour vos r�ponses !
Cordialement MoZo

[ManusDei]

Ca me para�t bizarre d'utiliser une structure.

Ils vont bien utiliser des fonctions pour cr�er, modifier, supprimer leurs tables, non ?

Vu que la fonction devrait �tre diff�rente selon l'objet, faire une classe, avec sa fonction interne me para�t �tre le truc le plus simple � utiliser.

Et surtout �a sera plus facile pour retrouver ses petits quand on y revient.

Ca �vitera que par erreur quelqu'un tente de sauvegarder une Personne en base en utilisant la m�thode pour sauvegarder les Produits.

[Mozofeuk]

En fait ils ont une interface contenant toutes les fonctions d'insert/update/delete pour toutes leurs structures.

En gros dans l'interface BDD, ils ont

Personne GetPersonneByID(int ID)
Produits GetProduitByID(int ID)
..
void AddPersonne(Personne)
void AddProduit(Produit)
...

et ainsi de suite pour tous les objets. Ils font �a car ils veulent poss�der plusieurs interface diff�rentes car la source de donn�es peut changer (Aujourd'hui Sqlite, demain sql server, Oracle..)

[ManusDei]

Y a aucune modularit� sur ce syst�me.
A supposer que tu veuilles sortir une autre version de ce que vous faites, sans la table Personne, tu es oblig� d'aller ouvrir des fichiers, et de supprimer des lignes.

Personnellement je trouve que �a fait un peu foutoir cette organisation.
L� �a reste probablement utilisable, si vous �tes limit�s � quelques tables, mais si le projet grossit, avec quelques ne serait-ce que quelques dizaines de tables diff�rentes, le fichier d'interface va devenir un vrai cauchemar, surtout si tu as des clients/utilisateurs diff�rents qui ont acc�s � des tables diff�rentes.

Alors qu'en faisant des objets, tu peux utiliser un syst�me plus simple.
Ou alors un fichier .h avec ta struct et les fonctions associ�es, et un fichier .c avec les corps de fonctions. Mais une fois l�, tu peux passer tes struct en objets, et profiter des avantages objets (private, public, etc....) que tu n'as pas avec les struct.

Vouloir garder des struct au lieu des objets simplement � cause du constructeur, c'est... bizarre, car ton struct, il va bien falloir le remplir, donc d�finir un "constructeur" de struct.

Edit : en plus, avec l'objet tu d�finis une fonction add(), une fonction save(), et tu t'emb�tes pas � devoir mettre le nom de la struct/objet dans le nom de la fonction. C'est du gadget, mais je vois pas de raison pour que deux fonctions qui font la m�me chose (ajouter un "truc") aient des noms diff�rents.

[10_GOTO_10]

En C++, les classes et les structures sont exactement la m�me chose, autant en ce qui concerne les possibilit�s que les performances.

La seule diff�rence est qu'une structure a ses membles public par d�faut alors qu'une classe les a en private (mais on peut tr�s bien mettre "private" dans une structure, et dans ce cas il n'y a plus aucune diff�rence).

A part �a, tout ce qui peut �tre fait avec une classe peut l'�tre avec une structure: h�ritage, m�thodes, constructeurs, etc... Ce n'est ni moins rapide ni moins long � �crire (� part le fait d'�crire "public:").

Voir le cours de C++: http://cpp.developpez.com/cours/cpp/?page=page_10#LX-D

[Mozofeuk]

Ce que tu conseil donc si je te suis bien, c'est de placer toutes les fonctions D'insert/delete/update dans chaque Classe/Structure Personne, Produit...
Chaque Classe/Structure aura donc sa(ses) propre fonction(s) d�crite dans sa classe.

Et de les surcharger si jamais on venait � changer de source de donn�es ?

Sinon, en fouillant un peu le net j'ai pu voir que en C++, il n'y a quasiment aucune diff�rence entre une structure et une classe mis � part le scope par d�faut :

There is a difference though, in C++ structure the
member variables and functions are public by default
while in a class they are private by default. AFAIK
that seems to be the only difference other than the
names themselves. I suppose under the hood structure
and class is seen differently but at a higher level
its almost the same

To cut a unnecesarily long discussion short , the only difference between a
struct and a class "IN C++" is that by default , the scope of a struct
variable is public in case of a struct and its private in the case of a
class. Other than that , a struct is capable of doing everything that a
class does in c++.

[bacelar]

En .NET (C++/CLI) une structure manag�e n'a rien de commun avec une classe manag�e.

En C++ natif, la diff�rence entre structure et classe est minime.
Il reste les "intentions" de faire de ces structures des "POCO" correspondant � des entit�s "inactives".
C'est quelque chose de tr�s commun dans des ORMs (Object Relationnel Mapper) car les objets contenants des donn�es doivent �tre facilement serialisables, ne pas perturber inopin�ment les m�canismes internes des ORM, etc..

Voir aussi les DTO (Data Transfert Object).

N'aillez pas une vue trop restreinte de la conception objet.
Beaucoup des Design Patterns efficaces malm�nent souvent la conception objet extr�miste.

[Mozofeuk]

Bacelar tu dis que en C++ sous Visual studio, donc en C++ CLI, une structure et une classe n'ont rien � voir ?

Pourquoi ?

[bacelar]

donc en C++ CLI, une structure et une classe n'ont rien � voir

Je parle de structures et de classes MANAGEES.

Bacelar tu dis que en C++ sous Visual studio, donc en C++ CLI,

C++ sous VS <> C++/CLI.
La majorit� du code C++ sous Windows est du C++, PAS en C++/CLI.

Un lien pour les d�clarations d'objet manag� en C++/CLI.

http://www.codeproject.com/KB/books/...ionCh1Ex1.aspx

[Mozofeuk]

Ok, merci pour toutes ces pr�cisions