Je vois beaucoup de topics où l'on martelle qu'il faut programmer objet.
Est-ce que c'est vraiment mieux ou bien est-ce la mode à cause de JAVA?

C++ rullez
c mieux l'objet

Ca c de l'argumentation!  
Je veux savoir quel est l'avantage principal?
programmes plus rapides?
Programmes qui plantent moins? (alors Billou y connait pas)
Programmes plus faciles à développer? A maintenir? a comprendre?
 
Si je te demandes: à ton avis quelle est la propriété la plus importante de l'objet tu me dit quoi? ( sérieux svp)

l'objet permet ou améliore
 
- la modularisation
- l'évolution d'un projet
- la réutilisation des dits objets dans divers projets
- de cacher des implémentations de fonction pour ne laisser transparaitre que la syntaxe
- de construire des objets plus compliqué a partir de simples (je sais ca peut paraitre con au départ)
- de penser plus naturellement (j'entend par la que les objets peuvent symboliser des objets de la vie réelle)
- ...
 
j'en oublie surement plein mais en gros ca te permet de t'éloigner un peu plus, une fois qu'ils sont concus, de la couche  matériel (alloc de mémoire, gestion de vecteur...) pour te consacrer plus sur le véritable problème d'algorithmique plutot que sur son implémentation

Gizmo,
 
"de penser plus naturellement (j'entend par la que les objets peuvent symboliser des objets de la vie réelle) "
 
La taxinomie, implique trop souvent un modèle de penser. Or tout n'est pas organiser selon ce modèle ou proche. Dans le cas de projet sortant des canons de programmation le C++ peut être une restriction dans la créativité. Personnelement il me dérange, et je sais que je ne suis pas le seul, mais bon en prog classique c'est interessant.
 
 
concernant
- la modularisation  
- l'évolution d'un projet  
- la réutilisation des dits objets dans divers projets  
 
c'est les phrases bateaux pour convaincre de l'interet du C++ , c'est plus du discours que du raisonnement. Un bon programmeur en C réutilise assez facilemnt son ancien boulot. en même temps je reconnais que, par exemple, j'utilise une classe de fonction B-TREE pur les chaines en mémoire et une autre pour les nombres entiers. Bref une par type alors qu'en C++ je pourrais définir une classe globale, mais bon c'est pas tout les module des programmes qui nécessitent ce genre de chose. De plus en C++ c'est un chouia plus lent a cause de la résolution de type, mais bon.
 
Bref ça a ses avantages mais c'est porfois etouffant le C++. Maintenant c'est mon avis a moi tout seul, comme un grand, je ne l'impose a personne .

Je voudrais être convaincu. Quelles propriétés de l'objet font que ce que tu as dit est vrai?  
Si je prend un langage comme modula2 (évolution du pascal), par rapport au C++. C'est nettement mieux au niveau de la modularité et du masquage de l'implémentation.
Les bibliothèques sont très réutilisables.
Effectivement, il manque l'héritage pour fabriquer des objets à partir d'autres plus simples.
Mais d'un autre coté, je peux toujours copier les sources d'un module l'enrichir avec de nouvelles fonctionnalités.
Je dis pas ça pour te démolir. Mais je me demande parfois si on nous bourre pas le mou avec l'objet. On voit tellement de programmes objets qui plantent autant que les autres.
Le sytème UNIX est écrit en C et a la réputation d'être assez robuste.
Allez continuez à me donner des raisons, de basculer dans le monde objet.  
Quel est le meilleur avantage d'un langage objet par rapport au langage fonctionnel?

les raisons communément mises en avant pour vendre l'objet sont très bien exposées par gizmo.
 
Ce qu'il faut prendre en compte aussi c'est l'aspect pratique de la chose. Sur des très gros projets (on va dire au delà de 100000 lignes de code), en C pur, c'est la débandade (collisions dans l'espace de nomage, effets de bord a la pelle, lisibilité douteuse, etc...). L'objet peut alors (ce n'est pas toujours le cas) faciliter énormément le travail.  
 
Si des règles simples ont été respectés tout au long de la phase de conception et de développement, tous les problèmes cités précédemment deviennent moins aigus : l'espace de nomage est préservé par l'encapsulation en classes, namespaces ou packages ; les effets de bord sont moindres, la lisibilité est accrue (les traitements et les données sont regroupés dans une même entité...).
 
Dans les phases de conception, l'objet permet également d'aller bien plus loin que la programmation procedurale. Le monde réel est constitué d'objets. Il suffit donc de bien observer et décrire ce que l'on voit pour avoir une première esquisse du système. Ensuite par abstractions successives du réel en "meta-reel", on isole les grandes classes d'objets et les comportements auxquels les objets doivent répondre.
Exemple:
la structure d'arbre, s'il faut la parcourir dans un langage comme le C, il faut écrire un algo (récursif ou non récursif) plus ou moins compliqué et non naturel : si vous donnez les lignes de code a un non initié, il faut qu'il déroule la boucle pour comprendre comment ca marche.
En objet, l'algo se résume à l'observation du modèle que l'on veut reproduire (ie l'arbre). Avec un peu d?entraînement, on arrive vite au design pattern composite et le parcours de l'arbre deviens alors un jeu d'enfant.
Exemple de dp composite :
 
etc. etc. etc. etc.

Bon alors je suis d'accord avec ce qui a été dit par gizmo et aussi par aqwsezsxdr.
 
Par contre je nuancerais les propos de aqwsezsxdr :  
tu peux écrire du code (gros projets) gérable dans n'importe quel language, la plupart des os sont ecrits en C (unix linux wuindoz ...) l'important est la rigueur du développeur.
 
l'avantage des langages objets c'est surtout que ça permet d'abstraire les données :
- ça permet par exemple de ne pas se faire chier avec les chaines de caractères comme en C, c'est hyper important ça évite entre autres les fuites de mémoire et les buffer overflow

salut tout le monde,
 
discussion interessante . Bon en gros je pense que le C++  c'est essentiellement bien pour :
 
1 - le travail de groupe
2 - developper des appli standard
 
Mais généraliser les interets du C++, je ne suis pas d'accord.
 
Ramarques concernant les quelques exemples (autant pour le C que le C++) :
 
1 - pour la récursivité : On propose trop souvent des modèles récursifs en enseignement. Mais d'un point de vue performance et possibilité d'optimisation, la version linéarisée est bcp plus interessante (parcours d'arbre, analyseur syntaxique, FFT, ...)
 
2 - Pour le buffer overflow, Si l'exemple auquel pense krolours 1 c'est la reception des param d'un CGI, alors il est assez simple de controler la taille de chaque param et le nombre.

Bonjour à tous et merci pour votre participation.
Je suis bien content de voir que aqwsezsxdr a une vue très saine de la programmation. IL FAUT EVITER LES EFFETS DE BORDS.
J'ai lancé ce débat car mon expérience avec les développeurs objets surtout la jeune génération m'a conduit à penser que c'est une technologie puissante mais dangereuse.  
L'utilisation trop intensive de l'héritage, pour factoriser du code et soit disant le rendre réutilisable conduit à des programmes touffus et peu compréhensible.
On met souvent trop en avant la réutilisabilité, en oubliant la robustesse et la maintenabilité.
En plus le langage phare est devenu le C++ pour des raisons historiques (compatibilité avec le C). Et comme langage tordu et dangereux il se pose là. Bonjour la lisibilité des programmes de soit disant artistes qui s'amuse sans arret à utiliser la redéfinition des opérateurs.
J'ai récupéré la maintenance et l'évolution d'une grosse application de gestion développée en langage objet sur une base Oracle. Un grand classique. Quand on m'a parlé de l'appli, la vanne qui revenait sans arret: Quand tu tire la chasse d'eau, ça éteint la lumière. Ils avait fait un super truc objet avec des hériatege dans tous les sens. Seulement tous les objets en mémoire attaque sans contrôle la base de donnée. Chacun y met se qu'il veut en plantant les objets du petit copain.
On devrait rappeler que l'idée fondammentale de la programmation objet c'est l'encapsulation avant l'abstraction. On évite ainsi les effets de bord.

Yep, de retour!
 
Bon, alors, visiblement, tout le monde semble s'être focalisé sur le C++. C'est un peu dommage car c'est loin d'être le seul a fournir l'OO et ce n'est pas non plus le plus sécurisé dans son utilisation.
 
Alors, pour répondre dans l'ordre:
 
Barbarella >>
 
Il est clair que suivant le type de programme a concevoir, l'OO n'est pas toujours approprié, c'est d'ailleur pour cela que les langages fonctionnells comme CAML ou Prolog ont toujours du succès. Mais ce qui fait l'attrait de l'OO, c'est justement, que l'on essaye de plus en plus de développer des application faciles d'utilisation pour tout public. Et dans ce cas, se rapprocher d'un modèle réel est bien plus facile.
Quand tu dis que tu réutilises du code, soit, mais visiblement, ce ne sont pas des grosses parties de codes. D'ailleur, en C, on a crée les "struct" pour commencer a aider les gens dans la modularisation. L'OO lui te permet de garder des modules entier pour différents programmes, et ainsi de ne pas les recompiler a chaque fois, ce qui peut prendre beaucoup de temps.
 
FastFreddo>> ce qui fait que beaucoup de programmes objet plantent, c'est d'une part que c'est un concept à la mode et que donc tout le monde et n'importe qui s'y met. D'autre part, la plupart des langages qui proposent l'OO ont du faire des choix sur la puissance de l'objet ou la sécurité de son utilisation. En C++, on a privilégié la puissance, ce qui approte come risque, celui de l'héritage multiple avec redondance d'héritage et donc conflits. En Java par contre, son utilisation est tellement sécurisée que le seul moyen de faire une simulation d'héritage multiple est d'utliser des interfaces, mais l'a, on perd l'homogénéité des objets.
 
Bref, l'idéal pour un langage OO serait d'avoir un compilarteur avec parcours topologique des arbres de dérivation, mais ca, c'est beaucoup plus lourd a la compil.

tu peux détailler pour les profanes ? merci

fastFredo>

On dirait que tu as hérité d'une usine à gaz... le problème vient de la conception de l'appli on dirait. Donc pas forcément lié à l'apprOOche. C'es un pb général : aucun développement ne peut se passer d'une étape de conception technique, à + forte raison lorsqu'il s'agit d'OO. Je sus sûr que sans OO, les objets en mémoire attaqueraient également sans contrôle la bd.

youdontcare a écrit a écrit :  tu peux détailler pour les profanes ? merci

 
bah, un des gros problème c'est quand tu fais des héritage comme ca:
 
Objet A
 
Objet B, hérite de A
Objet C, hérite de A
 
Objet D, hérite de B et C
 
Donc tu as dans D un double héritage de A et ceci est fait de manière invisible et donc en cas d'appel a une méthode de A on ne sait pas vers quel A on doit se tourner (c'est le même mais le programme ne le sait pas). Donc une solution serait d'interdire ce tyoe de schéma. Pour ce faire, il faudrait parcourir l'arbre (la foret) des objets et vérifier qu'un objet n'hérite pas  fois d'un même objet, quelque soit son niveau d'héritage. Le problème, c'est que si cette méthode est trsè facile a appliquer dans un petit programme, dèsque tu te met a travailler en module, ca devient plus compliquer. En effet, il faut aller aussi regarder dans tous les autres modules, peut-être déja compilé, vérifer les nom ainsi que les structures des objets, et on peut remonter très haut. En Java, par exemple, c'est pratiquement impossible, vu que TOUT est censé dériver d'une seule et même class "Object".

 
En général le double héritage est déconseillé. D'ailleurs bcp de language OO ne le propose pas (Java par ex).
 
Sinon je trouve que le C++ c'est jamais que des structures avec fonctions en plus. Et ca ca change tout
De plus avec quelques nouveautés dans la syntaxe, passage par référence (&) et les const sur les paramètres, ca rend le code plus "fort" syntaxiquement et évite pas mal de conneries (à la compil) qu'on peut faire en C avec les pointeurs.

La réutilisation est justement là pour éviter le copier/coller.
Le copier/coller est un des meilleurs moyens qui soient pour obtenir un code touffu et difficile à maintenir. D'abord parce que les 2 bouts de code censés être identiques ont toujours tendance à diverger (or, une des principales sources de bugs, c'est quand un programmeur croit que le code sur lequel il travaille se comporte d'une certain façon, alors qu'il se comporte différemment). Ensuite, une des règles de base de la qualité logicielle (règle empirique, certes, mais à ma connaissance jamais démentie), c'est que le nombre de bugs est toujours proportionnel au nombre de lignes de code. Le coefficient peut changer selon les personnes et les équipes, mais la règle est vraie quel que soit le langage, et le coefficient ne change pour ainsi dire pas en changeant de langage.
Donc duplication de code => nombre de bugs statistiquement multiplié par 2.
 
Freddo> J'ai vu des tas de gens prétendre programmer objet alors qu'ils faisaient du (mauvais) modulaire à la sauce objet. Ainsi que tu l'as dit, le principe premier de l'objet, c'est l'encapsulation, l'abstraction des données n'étant qu'un corollaire de ce principe d'encapsulation. Et la base de données doit elle aussi subir ce principe. Donc si base de données il y a, il doit y avoir un petit nombre de classes dont le but est de faire l'interface avec la base de données. Et seuls ces objets-là peuvent faire accès à la base de données. Sinon, c'est que tu as un problème d'architecture de ton logiciel.
 
Mais tu sais, on peut tout à fait appliquer les principes et la philosophie objet en assembleur ! (je l'ai déjà fait ). Le langage n'est qu'un outil pour exprimer ses algorithmes, et la façon dont ils interagissent, donc certains langages te permettent d'exprimer plus facilement ta pensée (et vérifient mieux la cohérence de ta pensée, ce qui est un plus), mais c'est tout.
 
Enfin, pour aller dans le sens de gizmo, C++ n'est pas le meilleur langage à objets qui soit, quand on s'intéresse à la sécurité de programmation qu'offrent les techniques objet. Et de ce point de vue, C++ est aussi victime de la compatibilité ascendante qu'il offre avec C (que je trouve une mauvaise chose, personnellement-moi-même ).

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

salut,
 
"(règle empirique, certes, mais à ma connaissance jamais démentie)"
 
Sans offense pour toi, je connais aussi cette règle mais elle est stupide . Elle n'est applicable que si les équipes de dev ont des modes opératoires ou protocoles de test qualité similaire.
 
En particulier ce qui défini le nombre de bugs est le tps homme/machine dans la phase de débogue. Si tu passes 1 heures sur 1 million de ligne de code, je donne pas cher de ta peau lors de la commercialisation du prog . Si t'y passe 10000 heures/homme ça sera nettement mieux.

bararella> Tu parles du coefficient, pas du caractère linéaire de la règle quel que soit le langage.
 
Je sais bien que selon les équipes, on peut aller de 0,1 bug pour 1000 lignes de code (ça, c'est bon) à 100 bugs pour 1000 lignes de code (ça, c'est franchement mauvais). Mais pour une équipe donnée, le caractère linéaire de la règle reste, (j'insiste encore) quel que soit le langage.
 
Je sais aussi que ce n'est qu'une métrique parmi tant d'autres, qu'elle a ses limites (vite atteintes), mais une métrique comme ça vaut mieux que pas de métrique du tout. Et à l'ignorer, on tombe très vite dans contre quoi cette métrique est censée vous prémunir : se donner les moyens d'avoir du code de bonne qualité, et réduire autant que possible les coûts de maintenance et de correction de bugs une fois le logiciel en production.
 
Et contrairement à ce que tu dis, ce n'est pas le temps (ou le ratio de temps) de débogage qui est le plus important. C'est le temps passé en amont...

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

Pour la métrique. La on est d'accord elle est variable
 
"Et contrairement à ce que tu dis, ce n'est pas le temps (ou le ratio de temps) de débogage qui est le plus important. C'est le temps passé en amont... "
 
Ca devrait l'être ! Mais c'est pas tout a fait ce que j'ai dit. Pas grave je vais me coucher j'ai chopé une angine aujourd'hui j'suis naze
 
@++

Salut à tous
 
Barbarella --> moi aussi je sors d'un angine.
BifaceMcLeOD --> Je suis bien d'accord avec toi quand tu dis que ce n'est pas le langage qui compte mais plutôt la conception.
En gros vous vous rejoignez sur le plan de la robustesse des programmes: Pour augmenter la fiabilité, il faut réduire la complexité.
Un programme facile à maintenir est un programme facile à comprendre.  
Regardez ce que vous faites quand vous débugguez.
C'est un véritable travail d'enquête pour reconstituer les évènements puis comprendre la cause et enfin la pluspart du temps corriger la ligne incriminée: 80% de temps de recherche et réflexion 20% de temps de correction et de test. Il est évident que c'est sur les 80% qu'il faut porter son effort d'optimisation.
 
Mais la plus grande partie de la maintenance, c'est faire évoluer les programmes pour s'adapter aux changements (Ca fait six mois que la boite se prépare à l'euro).   Enfin je l'espère pour vous, car le debugging c'est chiant.
Et là, l'objet mal utilisé, ça peut être très pénible.  
L'idéal pour avoir une application évolutive, c'est d'avoir des modules très faiblements couplés. Ainsi quand on fait évoluer un module ou un ensemble de module liés à la modification d'une fonctionnalité, moins il y a d'interaction avec les autres moins on aura de soucis.
L'héritage est le plus fort couplage que l'on peut avoir entre 2 classes. Donc il faut l'utiliser à bon essient.
Si l'on factorise du code dans une classe mère A, pour deux classes filles B et C, on a intéret à avoir des caractéristiques très stables dans A. Sinon toute évolution de A impacte les trois classes. Le pire étant quand B et C sont dans des dommaines fonctionnels différents qui évoluent indépendamment.
Je vais essayer de faire un modèle UML simplifié avec un cas concret que j'ai à résoudre aujourd'hui.
Je le prépare et je reviens.
A plus.