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