Qu'est-ce qu'on peut faire avec l'approche Objet qu'on ne peut pas faire avec une approche structurel? (je veux dire dans la pratique)

De plus, rien.
C'est juste une approche sans doute plus adaptée à des prochains complexes où on cherche à séparer des parties en éléments peu dépendants, exposant entre eux des interfaces.
A partir de là on peut parler de conception objet.
Et ça peut se faire avec des langages non objet. De nombreux frameworks applicatifs ont été écrits en Pascal ou en C.
 
Puis de langages vraiment objets sont apparus (Smalltalk par exemple) pour explorer plus en avant ce concept.
Mais même en C++ ou en Java (avec des méthodes statiques) on peut faire de la prog classique, comme en C.

DOnc ça sert à rien de me mettre à penser objet? Parceque je suis en train d'essayer d'y passer et j'ai l'impression que ça pose plus de problème que ça n'en résout...

Disons que dans l'absolu non.
Mais dans pas mal de cas, l'approche objet représente un réel gain.
La conception objet est apparu naturellement à bcp de développeurs alors même qu'il n'existait aucun langage objet.  
C'est une méthode tout de même efficace et quasiment "obligatoire" aujourd'hui dans le monde pro.

Hum par exemple l'héritage... j'ai l'impression qu'avec des structure imbriqué les une dans les autre je fait pareille en C qu'avec des clesse en C++ sauf que avec les classes ça devient vite le bordel avec les fonction amis, les héritage protéger... du coup je met tous les membre de mes classes en Public (parceque sinon je faisais une méthode set et une méthode get pour chaque données et que ça revenait au même que tout laisser en public) puis avec les référence qui ne sont pas mieux protéger que les pointeurs mais qui sont moins transparent (au moins avec un pointeur on savais qu'il fallait faire gaffe...)
Donc je me disais que quitte à faire la séparation Interface<->Donné je le faisais mieux en C avec des struct et de jolie fichier en tête ...

sombresonge a écrit a écrit : Hum par exemple l'héritage... j'ai l'impression qu'avec des structure imbriqué les une dans les autre je fait pareille en C qu'avec des clesse en C++ sauf que avec les classes ça devient vite le bordel avec les fonction amis, les héritage protéger... du coup je met tous les membre de mes classes en Public (parceque sinon je faisais une méthode set et une méthode get pour chaque données et que ça revenait au même que tout laisser en public) puis avec les référence qui ne sont pas mieux protéger que les pointeurs mais qui sont moins transparent (au moins avec un pointeur on savais qu'il fallait faire gaffe...) Donc je me disais que quitte à faire la séparation Interface<->Donné je le faisais mieux en C avec des struct et de jolie fichier en tête ...

 
  cai pô bieng comme dirait l'autre
 
1. Les get et set sont pas la pour faire chier le monde, ca sert juste à encapsuler l'acces à tes attributs. Comme ca, tu peux faire plein de choses en plus : tests, transformations etc qui te permettent de t'assurer de la coherence interne de ton objet. Si tu mets tout en public ou ds une structure, tu ne pourra jamais etre sur que l'utilisateur n'initialisera pas sa classe Point avec des coordonnées en spherique alors que toi tu l'as concu pour marcher en cartezien...
 
2. L'heritage et le polymorphisme, c'est le deuxieme point fort de l'objet qui apporte bien plus que la simple aggregation d'une structure dans une autre. Il est vrai, qu'on peut se creer ses propres vtables en C à partir de pointeurs vers des fonctions, mais c'est bcp plus lourd et moins naturel que l'utilisation tres simple du mot clef virtual.
 
3. Les references, c'est pas compliqué, à la limite, en dehors de qcq cas bien precis (operateur de recopie, cstr de recopie redefinition d'operateurs...) tu peux les oublier.

 
le problème c par exemple:
 
toto& fonction()
{
  toto MonToto;
   
  .
  .
  .
 
  return MonToto;
}
 
On retourne quoi? un pointeur? une recopie? j'y comprend rien à cette syntaxe !

sombresonge a écrit a écrit :     le problème c par exemple:   toto& fonction() {   toto MonToto;       .   .   .     return MonToto; }   On retourne quoi? un pointeur? une recopie? j'y comprend rien à cette syntaxe !

Ca, c'est justement le code à ne pas écrire avec des références

une référence est tout simplement un alias  

Verdoux a écrit a écrit :   Ca, c'est justement le code à ne pas écrire avec des références

 
N'empeche que c des trucs que l'on voit de temps en temps dans des tutoriaux...

C_Po_Ma_Faute a écrit a écrit : une référence est tout simplement un alias

 
Certe et une classe dérivé c une sorte de classe de base et un cercle c'est une sorte d'ellipse et mon programe il plante bizarement !
 
Sérieusement Physiquement une référence c quoi? un pointeur déréférencer? une variable de recopie?

cauchemar (desolé pour la blague cetait trop tentant),
est-ce que ca te viendrait à l'idee d'ecrire avec des pointeurs
 
toto * titi()
{
  toto unToto;
 
 
 
  return &unToto;
}
 
avec les references c'est exactement pareil, utilise les comme des pointeurs (sauf ke pour acceder à des mebres d'un obj passé par ref tu utilise le . à la place de -> )
 
ton code, il pourrait s'ecrire pour utiliser la recopie :
 
toto  titi()
{
  toto unToto;
 
 
 
  return unToto;
}
 
auquel cas, c'est pas une ref que tu retournes mais un obj qui va etre recopie de sur la pile vers ton objet à toi.
 
Certe et une classe dérivé c une sorte de classe de base et un cercle c'est une sorte d'ellipse et mon programe il plante bizarement   !
 
un cercle c'est une ellipse et ca peut aussi etre vu comme un objet graphique. Or un objet graphique, la moindre des chose c'est qu'il puisse etre dessiné. Donc si jamais t'as une liste d'obj graphiques (peu importe ce qu'il y a dedans : cercles, elipses, carres....) si tous savent repondre au message dessine toi !, c'est parfait, tu itere cette requette sur toute ta liste et tout se dessine comme par magie pas la peine de connaitre les types de ce ke t'as ds la liste...

comme le disait C_Po_Ma_Faute, une référence est un alias : c'est juste un nom différent pour la même variable.  
 
int a = 4;
int& b = a; // b référence a
 
tu peux maintenant utiliser b ou a indifféremment pour accéder à la variable. en interne, les pointeurs sont identiques : &a (adresse de a) est égal à &b (adresse de b).
 
c'est pour ça que ton exemple ...
 
toto& fonction()  
{  
 toto MonToto;  
 return MonToto;  
}  
 
... ne marche pas, car tu retournes une variable temporaire (allouée sur la pile) qui est détruite en sortie de la fonction.
 
concrètement, à quoi ça sert ?
 
* à garantir que l'objet est non null :
 
void myFunc(myObject& a)
{
}
 
te garantit d'avoir un objet valide dans a. si tu étais passé par un paramètre myObject* a, il aurait fallu tester s'il était null. (ok, pour les programmeurs tordus, on peut passer un *pointeur en paramètre, mais bon).
 
* à donner un nouveau nom à une variable au nom complexe que tu utilises souvent :
 
myObject.myPoints[i].rx = myObject.myPoints[i].x * cos(a) - myObject.myPoints[i].y * sin(a);
 
peut être remplacé par
 
Point& p = myObject.myPoints[i];
p.rx = p.x * cos(a) - p.y * sin(a);
 
* à chaîner les appels. une classe dont les méthodes retournent la classe utilisée permet de faire de la haute voltige :
 
class myWorld
{
  myWorld&  ProcessInput();
  myWorld&  UpdateWorld();
  myWorld&  Render();
  myWorld&  BlitScreen();
}
 
les méthodes étant définies comme
 
myWorld& myWorld::ProcessInput()
{
  // le code ...
  return *this;
}
 
tu peux alors faire :
 
myWorld world;
world.ProcessInput().UpdateWorld().Render().BlitScreen();

[edtdd]--Message édité par youdontcare--[/edtdd]

LE problème récurrent
 
un cercle est une ellipse particulière. quand on dérive les formes graphiques d'une classe de base, faut-il dériver cercle de ellipse ou ellipse de cercle ? hmmmm

Autre problème qui me semble insoluble: J'ai essayé d'empaqueter une fenetre dans une classe, me suis dit ce serra cool comme ça j'aurrais qu'à faire dans l'avenir
 
#include "MaFenetre.h"
 
...  
WinMain()
{
  MaFenetre Fenetre(640,480,16);
  .
  .
  .
  MaFenetre.GereMessage();
  .
  .
  .
}
 
Mais je suis tombé sur un os: il est impossible de convertir un pointeur this->point_sur_fonction en void*!
 
Du coup lorsque par exemple il faut spécifier à windows la fonction callback de gestion de fenetre on peut pas lui passer une fonction membre d'une classe, d'où on est obliger de gérer ça par des fonction global d'où on peut pas accéder au membre privé à partir de la fonction callback. Finallement j'ai été obligé de mettre tout un tas de membre de ma classe en public...

la solution c'est une methode statique de ton objet fenetre

 
Là je comprend plus... myWorld& c une référence à *this??? et *this c l'objet. Donc myWorld est un alias de l'objet? mais this n'existe-t-il pas à l'extérieur de l'objet?

 
J'y ai penser sauf que:
 
WNDPROC Fenetre::winproc() != WNDPROC winproc() !!!!

 
ca devrait pourtant passer un  
 
static WNDPROC Fenetre::winproc()
 
j'ai pas teste avec la pompe a messages mais par contre avec
les threads oui (et c'est un cas similaire), on a besoin de passer en param d'une fonction de l'API, un ptr vers une autre fonction qui sera le corps du thread...

 
faut pas t'emeller les idees comme ca, qd tu dereference un pointeur, t'obtiens une reference donc *this est une ref vers ton objet. Par contre, ici, l'objet pointé par this n'est pas du tout alloué sur la pile de la methode myWorld:: ProcessInput(), il a soit ete alloué via un new sur le heap, soit sinon, alloué sur la pile de la methode qui appelle le myWorld:: ProcessInput()
donc, retourner une reference *this, ne presente pas de danger particuliers.

[edtdd]--Message édité par wpk--[/edtdd]

Je crois que pour l'instant je vais laisser tomber les référence... je devrais pouvoir m'en sortir avec mes pointeurs (enfin j'espère).
 
Pour la fonction callback le seul truc qu'a marcher c'est:
 
class MyWin
{
public:
  ...
  static gestfenetre();
  ...
}
...
 
MyWingetfenetre()
{
 ...
}
 
...
 
WNDPROC GlobalWindowProc()
{
  MyWin::gestfenetre();
}
 
MyWin::Init()
{
  WNDCLASS wc;
  ...
  wc.lpfnWndProc = GlobalWindowProc();
  ...
}
 
 
C quand même un peu lourdingue!!!

sombresonge a écrit a écrit : Qu'est-ce qu'on peut faire avec l'approche Objet qu'on ne peut pas faire avec une approche structurel? (je veux dire dans la pratique)

 
Dans la pratique, pas grand chose en plus mais à ce compte là, pourquoi ne pas programmer en Assembleur au lieu du C ?  
 
L'objet permet un niveau d'abstraction supérieur à celui du C lui même supérieur à celui de l'ASM.

quand je lis tout ca, je me dis  : vive le java !!!!

benou a écrit a écrit : quand je lis tout ca, je me dis  : vive le java !!!!

 
alors là ce serais un autre débat
débat lancé maintes fois sur ce forum ... quel est le meilleur langage ? en quel langage préférez vous programmer ? ... ne nous emportons pas !!!  

désolé ... ca a été plus fort que moi ...

 
Quand je programe en C il m'arrive de mettre des bout de code en assembleur inline justement