Discussion :

[super_navide]

Par conception Objet j'entend faire des diagrames de classes , des diagrame de séquence.
Je sais que implémenté une classe en C c'est possible mais c'est lourd ...
Montre moi comment on implemente facilement une classes avec une hierarchie en c , comment on fait des appels de méthode , comment on définit des méthodes...
De toutes façon les langage sont traduit en assembler (ou c ) donc théoriquement c'est possible de faire de l'objet avec de l'assembler mais a quel prix...
Les compilateurs sont concu poru facilité le travail...

[Jean-Marc.Bourguet]

Montre moi comment on implemente facilement une classes avec une hierarchie en c , comment on fait des appels de méthode , comment on définit des méthodes...

http://ldeniau.web.cern.ch/ldeniau/oopc.html

[super_navide]

A oui super , génial c'est super simple je vais dévoppé tous ce que je fait en C maintenant...

Je me demande pourquoi sun a créer Java et Microsoft C# alors qu'on peut

faire avec une bonne conception objet n'importe qu'elle application en C.



Merci quand même pour l'adresse du site car par contre ca permet de mieux comprendre les fonctionnement interne des langages objet.

[millie]

Il faut bien comprendre que la conception orienté objet, c'est avant tout la conception de type abstrait de donnée. Et de tel type s'écrive très bien en C... Je ne vois pas le problème.

[Jean-Marc.Bourguet]

Je me demande pourquoi sun a créer Java et Microsoft C# alors qu'on peut faire avec une bonne conception objet n'importe qu'elle application en C.

Il y a des moments ou le C est le seul langage pratiquement utilisable. Et quand tu te trouves dans cette situation, ca ne doit pas t'empecher d'utiliser une conception OO.

[super_navide]

Non non et non, je me souvient de mes cours d'algorithmique .
les TAD : type abstrait de données .
ca n'a rien a voir avec de la conception objet.
C'est une façon de concevoir pour de la programation fonctionnel.
C'est a dire faire de l'agorithmique pour résoudre des problèmes qui sont assez méthamatique ...
Et heureusement qu'on peut le faire en C,sinon le C ne servirai a rien.

La conception objet étant tous les concepts de ce type de conception.

Exemple
soit le TAD : Liste
on définit les APIs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void ajout(Liste liste , Objet objet )
int taille(Liste liste )
boolean estListe(Objet objet )
Liste transformeEnListe(Objet objet)
void supprime( Liste liste , Objet objet )
Objet elementPour(Liste liste , int index )
void mettreElementPour(Liste liste,int index,Objet objet ) 
void inserer(Liste liste, int index , Objet )

Une Conception Objet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
interface Liste { 
void ajout(Objet objet )
int taille()

void supprime(  Objet objet )
Objet elementPour( int index )
void mettreElementPour(int index,Objet objet ) 
void inserer(int index , Objet )
}

[millie]

Non non et non, je me souvient de mes cours d'algorithmique .
...
C'est une façon de concevoir pour de la programation fonctionnel.

Je crois que tu te souviens mal. La programmation fonctionnelle n'a aucun rapport avec ça, elle se fait en général avec des langages fonctionnels comme Lisp. Un type abstrait de donné peut être utilisé avec d'autres paradigmes de programmation.

(voici une définition que j'avais déjà donné dans un autre post)
Pour faire simple, un type abstrait de donnée est un objet qui dispose d'un ensemble d'opérations ayant chacun une syntaxe et une sémantique.

De manière plus formelle, un type abstrait dispose :
- d'une signature qui comprend le nom du type (par exemple entier) et qui comprend le prototype de ses opérations
- d'axiomes qui définissent toutes les propriétés de ses opérations



Par exemple pour la pile

On définit une pile. Ses opérations et leurs prototypes sont :

- pileEstVide(Pile) -> Booléen
- pileCreer() -> Pile
- pileLire(Pile) -> Element
- pileEmpiler(Pile, Element) -> Pile
- pileDepiler(Pile) -> Pile

Les axiomes sont les suivants :
Pour toute pile p, pour tout élement e :
pileLire(pileEmpiler(p, e)) = e
p = pileDepiler(pileEmpiler(p,e))
pileEstVide(pileCreer()) est vrai

Les opérations suivants ne sont pas définis :
pileDepiler(pileCreer())
pileLire(pileCreer())

Les axiomes suffisent à eux seuls a déterminer d'une série d'instruction utilisant une pile.



A noter qu'il y a une définition avec un paradigme logique ici. Il est évidemment possible de donner des implémentations impératives qui respectent cette logique.



Maintenant, noté plutôt sous forme d'une classe avec des méthodes encapsulées, c'est pas vraiment différent, ce n'est qu'une question de notation.

[souviron34]

Bon super_navide là tu ne fais pas progresser le débat. Tu es convaincu de ce que tu dis et tu n'avances pas d'arguments réalistes.

Et pour ton exemple, je ne vois pas en quoi il est "attaché" à un langage objet. Je peux te citer des dizaines d'exemples en C ou autres qui font ça...

Un exemple de chez moi (en C) d'une série de fonctions (.h) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
extern MCore_Data *MCore_DataCreate                    ( MCore_DataSet *parent, int NumSource, 
						         int NLocations, int NumLocation );

extern int         MCore_DataDestroy                   ( MCore_Data *data );

extern int         MCore_DataSetCreate                 ( char            *DatatypeString,
						         int              computetype,
					                 MCore_DataSet  **sets,
					                 int             *nsets );

extern int         MCore_DataSetDestroy                ( MCore_DataSet *set );

extern int         MCore_ClearDataSet                  ( MCore_DataSet *set );

 
extern Boolean     MCore_IsDataTypeAForecast          ( int datatype );
 
extern Boolean     MCore_IsDataTypeGraphics           ( int datatype );
 
extern int         MCore_IsDatatypeComputable         ( int datatype );

extern Boolean     MCore_IsDatatypeContourable        ( int datatype );

Quant aux exemples de JM et gorgonite ou Woufeil, j'y reviendrais cette semaine, je viens de rentrer..

[super_navide]

toi non plus
Il y a 10 ans je suis d'accord la conception objet en C avais peut-être un avantage a cause du manque de maturité de java .
Mais de nos jours , on peut toujours ce passer d'un conception objet en C et utiliser une conception de type programmation fonctionnel (utilisation de TAD )
Ensuite faire une library static ou dynamique et l'utiliser dans un langage de plus haut niveau (c++ ou java c# python etc... )

On peut utiliser la conception Objet en C (cf le site que tu ma donné ) pour construire un Langage et un compilateur pour traduire ce Langage en C

Il faut distinguer de type de problèmatique
trouver un alogorithme
trouver une structure de données

[millie]

et utiliser une conception de type programmation fonctionnel (utilisation de TAD )

Tu n'as pas lu ce que j'avais écrit... La programmation fonctionnelle n'a pas de rapport avec les types abtraits de donnée. Il est possible d'utiliser des TAD avec d'autres paradigmes de programmation.

La programmation fonctionnelle n'est en générale correctement utilisable, qu'avec des langages fonctionnels (comme lisp, caml)

[super_navide]

Tu n'as pas lu ce que j'avais écrit... La programmation fonctionnelle n'a pas de rapport avec les types abtraits de donnée. Il est possible d'utiliser des TAD avec d'autres paradigmes de programmation.

La programmation fonctionnelle n'est en générale correctement utilisable, qu'avec des langages fonctionnels (comme lisp, caml)

ok oui d'accord

[Air Marty]

Re-bonjour,
c'est plus fort que vous vous ne pouvez pas vous empêcher de vous chamailler, on vous parle conception et vous répondez langage, on vous parle concepts/principes et vous répondez technique, ah les puristes !

Ce que je vais retenir des récents posts (et ce avec quoi je suis d'accord) :

• Bien plus que la programmation objet en elle même c'est vraiment le concept objet et ce qu'il peut apporter lors de la conception qui a une valeur ajoutée.

Beaucoup trop de développeurs pensent faire de l'objet alors qu'ils se contentent de savoir maitriser un langage.
Mon expérience personnelles me fait dire que l'avènement du C++ comme standard dans l'industrie n'est pas une complète réussite, à force de trop vouloir faire de la programmation objet au lieu de faire de la conception objet on se retrouve à faire du C--.
Mon commentaire peut paraitre un peu désabusé mais c'est mon quotidien, j'ai pris le C++ à titre d'exemple car c'est ce que nous utilisons en majorité dans mon service.

L'idéal étant bien sûr une belle conception et une implémentation digne de ce nom avec le langage le plus approprié au contexte technique (pourquoi pas tout en objet bien sur).

[super_navide]

Ca c'est vraiment une mode de vouloir séparer la Conception de la Programmation objet .
De vouloir faire un truc indépendant du langage.
Une conception objet est lié a l'implementation donc au langage
Il y a de très grosse différence technique entre les langages

Smalltalk :
heritage simple
possède un garbage collector
on peut continuer le code après une exeption
Closure (notion de lambda )
Metat model en ecriture et en lecture et Meta classe
non typé
pas de thread (dans la plupart des implémentations )
interfacage de DLL directe (pas de code supplémentaire )
Debuggage dans la même machine virtual ( dans le même process )
Modification de classe a l'excution possible pas de limitation
Appel dynamique de méthode ( excution d'une méthode dont le non est connu qu'a l'execution )
Portable

Java 1.5
typé
garbage collector
type générique
simple heritage de classe
heritage multiple d'interface
notion d'interface
thread
Meta model en lecture , pas de meta class
Closure (sorte de lambda ) en utilsant les classes anonymes mais très lourd syntaxiquement
pas de debuggage dans le même process
modification de classe a l'execution mais très limité (pour l'instant )
Appel dynamique de méthode
Portable
interfacage DLL complexe il faut développé une couche suplémentaire (
remarque il existe un framework payant pour interfacé une DLL sans dev supplémentaitre )

C++
typé
pas de garbage collector
type générique
heritage multiple de classe (heritage très riche )
thread
pas de Meta model en lecture , pas de meta class
pas de closure (sorte de lambda )
pas de debuggage dans le même process
modification de classe a l'execution impossible ou très très très limité
pas d'appel dynamique de méthode
Pas Portable
interface DLL sans dev supplémentaire

La liste des différences n'est pas complète mais elle montre que des la conception objet il faut pensé au langage avoir un bonne productivité et de bonne performance pour le logiciel .

avant la conception il faut savoir dans quel langage on va implémenté.


example si on développe une classe Collection
en Smalltalk
on va modéliserla classe avec une méthode Collection>>do: unBlock
pour parcourir la classe c'est plus propre

en Java et en C++
on utilisera un énumerateur

[souviron34]

Re-bonjour,
c'est plus fort que vous vous ne pouvez pas vous empêcher de vous chamailler, on vous parle conception et vous répondez langage, on vous parle concepts/principes et vous répondez technique, ah les puristes !

Ce que je vais retenir des récents posts (et ce avec quoi je suis d'accord) :

• Bien plus que la programmation objet en elle même c'est vraiment le concept objet et ce qu'il peut apporter lors de la conception qui a une valeur ajoutée.

Beaucoup trop de développeurs pensent faire de l'objet alors qu'ils se contentent de savoir maitriser un langage.
Mon expérience personnelles me fait dire que l'avènement du C++ comme standard dans l'industrie n'est pas une complète réussite, à force de trop vouloir faire de la programmation objet au lieu de faire de la conception objet on se retrouve à faire du C--.

Rien à ajouter.. Je pense qu'effectivement tout est là-dedans :

on vous parle conception et vous répondez langage, on vous parle concepts/principes et vous répondez technique

et que la "mode" "bouche" le paysage, en assimilant langage et conception, principe et technique...

[Air Marty]

Ca c'est vraiment une mode de vouloir séparer la Conception de la Programmation objet .
De vouloir faire un truc indépendant du langage.
Une conception objet est lié a l'implémentation donc au langage
Il y a de très grosse différence technique entre les langages
Smalltalk : (...)
Java 1.5 (...)
C++ (...)
La liste des différences n'est pas complète mais elle montre que des la conception objet il faut pensé au langage avoir un bonne productivité et de bonne performance pour le logiciel (...)

Quelle érudition, je suis impressionné !
Je suis un tout petit peu d'accord avec toi mais pas complètement
Le choix du langage peut parfois se faire dès le cahier des charges, résumons (simplement) les étapes d'un projet logiciel :

1. le cahier des charges : expression du besoin par le client (ce que veut le client),
2. les spécifications : traduction du cahier des charges sous forme de fonctionnalités et d'exigences (ce que nous devons faire pour répondre aux besoins du client, le quoi),
3. la conception : solution proposée pour répondre aux spécifications (comment nous répondons aux spécifications pour donner satisfaction au client),
4. la réalisation : implémentation technique, c'est le résultat, ce qui va être utilisable par le client.

Bon je sais c'est un peu simpliste mais cela me semble assez clairement résumé ce que l'on rencontre dans la majorité des projets (sans entrer dans les détails). Il va de soi que tous les cahier des charges ne se ressemblent pas, certains sont assez ouverts et contiennent peu ou pas de préconisations ou exigences tandis que d'autres peuvent être très précis et faire référence à des contraintes techniques (performances, disponibilité, contraintes normatives, etc.).
Le domaine d'application peut conditionner fortement le choix du langage, les exigences dans les domaines comme l'automobile, l'avionique ou le militaire embarqué (à titre d'exemple) ont des contraintes normatives fortes qui empêchent d'office l'utilisation de certains langages.
C'est en cela que je suis d'accord avec toi, bien que faisant de la conception rien n'empêche de commencer à penser à l'implémentation, c'est d'ailleurs en cela que l'on reconnaitra un chef de projet expérimenté qui maitrise les techniques de développements.
Donc ne pas perdre de vue le déroulement d'un projet, la réalisation n'est pas une fin en soit, l'objectif étant de donner satisfaction au client en ayant réussi à respecter les critères : coût, délai et qualité.
Par contre je ne suis pas du tout d'accord avec toi la dessus :

avant la conception il faut savoir dans quel langage on va implémenter.

Ceci n'est pas obligatoire et n'est pas toujours possible en fonction du contexte du projet. Comme je l'ai déjà écrit, tant mieux si tout coule de source et que l'on puisse choisir un langage assez tôt en même temps que l'on se charge de la conception.
Mais j'insiste car pour moi ce sont bien deux activités distinctes et séparées, d'un côté la conception et de l'autre la programmation.

Pour finir :

il faut penser au langage avoir un bonne productivité et de bonne performance pour le logiciel (...)

Bien que ce ne soit pas le topic juste une petite parenthèse sur "la productivité" et "la performance" que tu cites, tu as oublié "la disponibilité", "la maintenabilité", "la facilité d'utilisation", "la testabilité" et "la fiabilité" (une partie de la norme 9126 à titre d'exemple).
En fonction de la maturité et des bonnes pratiques de chacun, les objectifs recherchés lors du choix d'un langage vont au dela de la "productivité" et de la "performance", je vais me contenter juste d'évoquer le côté normatif du code produit, le niveau de qualité ciblé (ISO, CMMI, DOD ?) le coût de la ligne de code que sera prêt à payer une entreprise, tout est à prendre en compte.
Tu n'as fait qu'effleurer du doigt une des problématique du métier d'ingénieur logiciel, je conçois et réalise (ou bien je fais concevoir et fais réaliser) des logiciels, avec quel niveau de qualité ? à quel coût ? mon logiciel doit-il être pérenne ? la garantie de maintenance s'applique sur quelle durée ?
Bref un vrai sujet à part entière, à aborder dans un autre topic, si vous êtes des ingénieurs alors faites un travail d'ingénieur mais rien ne vous empêche de faire de la technique et donc de la programmation.

[Caine]

Bonjour,

La programmation orientée objet ne se différencie pas de la programmation traditionnelle (procédurale ou fonctionnelle) par l’héritage ou le polymorphisme mais par la notion d’objet et de classe.

Une classe et son instance, l’objet, ne sont en aucun cas une équivalence d’un type de donnée dans la programmation traditionnelle. Un objet contient de manière intrinsèque ses attributs et ses méthodes. Ce qui ne sera jamais le cas dans un langage non orienté objet.

Certes pour les programmeurs aguerris que nous sommes, il est possible de simuler l’héritage et le polymorphisme mais pas l’objet. Quelque soit le langage procédural dans lequel nous singeons ces deux mécanismes, nous ne pouvons pas garantir la non régression du type ancêtre quand nous le faisons évoluer. Ceci est dû à une contrainte d’implémentation simple : Une fonction ne peut pas faire parti d’un type de donné. Au mieux on utilise une table de pointeur de fonctions, mais le code des fonctions est extérieur au type de donnée.

Dans la POO, l’objet contient pleinement son comportement. Dans la programmation procédurale, le TAD ne contient pas son comportement, il lui est assigné depuis l’extérieur.

Un exemple pour me faire comprendre : Une application doit dans une partie de son exécution dessiner des figures sur une surface.
Dans la programmation orienté objet, on pourra créer typiquement deux classes, la surface et la figure. La surface s’occupera de dessiner la figure en appelant sa méthode dessin. La classe ancêtre est alors la classe Figure. La classe Surface demande à l’objet de type Figure de se dessiner sans connaître au moment de la compilation le type réel à dessiner. Un objet instance d’une Surface dessinera donc sans modifier son code indifféremment une ligne, un rectangle, un triangle ou autre. C’est le polymorphisme.

Jusqu’ici rien qui ne soit reproductible en programmation traditionnelle. Mais en grattant un peu, c’est tout le contraire. La méthode Dessin de la classe Surface va naturellement prendre en paramètre un objet, une instance de la classe Figure. Ce qui signifie que nous avons la garantie que la méthode Dessin que nous appelons appartient bien à une figure. Notez que c’est notre seule garantie. Mais elle fait toute la différence en terme de cohérence et de maintenance de code. Si la classe Surface est validée et si la classe Figure est validée, alors l’algorithme de dessin est validé quelque soit le type réel à l’exécution de la Figure.

Dans la cas d’une implémentation procédurale, nous sommes certains qu’une erreur de codage dans le type spécialisé d’une figure introduira un comportement erroné dans le dessin de la surface. Nous passons une structure en C, un record en Pascal, une zone mémoire en assembleur qui contient à chaque fois un pointeur sur la fonction réelle à exécuter. Qu’elle garantie a-t-on que la fonction pointée n’a pas changé à l’exécution depuis l’initialisation de la variable ? Aucune si ce n’est la rigueur du programmeur.

Dans le cas de l’objet, c’est à l’étape de la compilation que sont détectés ces erreurs, tandis que dans la programmation procédurale ce sera dans la face de relecture de code ou de test. Il faudra de toute manière le vérifier. Pas dans le cas de la programmation orienté objet qui garanti que le comportement de l’objet durant toute sa vie est tel que nous l’avons programmé.

Un autre point que la POO garanti est l’initialisation conforme de l’objet à chacune de ses créations. Dans la cadre de la NOO (Non orienté objet), c’est encore une fois sur le cursus de développement que reposera cette assertion. Nous pouvons singer l’héritage, soit, mais comment garantir que l’objet ancêtre est initialisé avant l’objet fils à chaque création ? Encore une fois, ce comportement est externe à notre type dans le cadre NOO. Au contraire en POO, l’ordonnancement de l’initialisation est une certitude. Dans la programmation NOO, l’initialisation d’une variable d’un type est toujours extérieure à ce type (attention, les compilos modernes initialises certes les structures à la valeurs zéro, mais si nous avons besoin de valeurs non nulles). Dans la POO, l’initialisation de l’objet est interne à celui-ci.

La POO a pour but de permettre l’évolution du code en garantissant la cohérence ancêtre. Elle permet de capitaliser les algorithmes avec un comportement définit à l’exécution, en assurant l’impossibilité de régression de tels algorithmes.

Quand au débat, tout objet ou mixe, c’est un choix de conception. « orienté objet », ça veut bien dire qu’il faut avoir le choix. La bataille a fait rage au plus fort de l’effet de mode. Un langage devait devenir objet s’il souhaitait survire, c’est une bataille de part de marchés plus qu’informatique.

J’espère vous avoir convaincu que les deux ne sont pas antinomiques, mais certainement pas équivalent en terme de régression et de sécurité du code.

[InOCamlWeTrust]

La programmation orientée objet ne se différencie pas de la programmation traditionnelle (procédurale ou fonctionnelle) par l’héritage ou le polymorphisme mais par la notion d’objet et de classe.

Une classe et son instance, l’objet, ne sont en aucun cas une équivalence d’un type de donnée dans la programmation traditionnelle. Un objet contient de manière intrinsèque ses attributs et ses méthodes. Ce qui ne sera jamais le cas dans un langage non orienté objet.

C'est plutôt le contraire : simuler un objet (une structure) comportant ses méthodes (des pointeurs de fonctions) et ses attributs (ses champs de données autres que les fonctions), c'est très facile. L'héritage est aussi très facile, en autorisant un objet (une structure) d'avoir un lien (un pointeur en C) vers son objet ancêtre (sa structure ancêtre).

Certes pour les programmeurs aguerris que nous sommes, il est possible de simuler l’héritage et le polymorphisme mais pas l’objet.

Ben non (voir ci-dessus).

Ceci est dû à une contrainte d’implémentation simple : Une fonction ne peut pas faire parti d’un type de donné.

Ben non, car même en C les fonctions ont un type de données... et dans les langages fonctionnels, encore plus.

Un exemple pour me faire comprendre : Une application doit dans une partie de son exécution dessiner des figures sur une surface.
Dans la programmation orienté objet, on pourra créer typiquement deux classes, la surface et la figure. La surface s’occupera de dessiner la figure en appelant sa méthode dessin. La classe ancêtre est alors la classe Figure. La classe Surface demande à l’objet de type Figure de se dessiner sans connaître au moment de la compilation le type réel à dessiner. Un objet instance d’une Surface dessinera donc sans modifier son code indifféremment une ligne, un rectangle, un triangle ou autre. C’est le polymorphisme.

Non, c'est l'édition de liens dynamique (rien à voir avec les DLL, n'est-ce pas !).

Jusqu’ici rien qui ne soit reproductible en programmation traditionnelle.

Non, c'est tout à fait faisable en programmation traditionnelle.

Dans la cas d’une implémentation procédurale, nous sommes certains qu’une erreur de codage dans le type spécialisé d’une figure introduira un comportement erroné dans le dessin de la surface. Nous passons une structure en C, un record en Pascal, une zone mémoire en assembleur qui contient à chaque fois un pointeur sur la fonction réelle à exécuter. Qu’elle garantie a-t-on que la fonction pointée n’a pas changé à l’exécution depuis l’initialisation de la variable ? Aucune si ce n’est la rigueur du programmeur.

Le segment de données ne peut jamais être écrit, donc la fonction pointée reste toujours la même. D'un autre côté, on ne raisonne pas au même niveau : la simulation d'un langage objet par un langage non objet est déjà an soi une implantation de ce langage objet : si l'implantation est bugée, tu auras forcément des problèmes à l'exécution... et si ton compilateur pour ton langage objet est buggé, tu auras aussi de sérieux problèmes...

Un autre point que la POO garanti est l’initialisation conforme de l’objet à chacune de ses créations. Dans la cadre de la NOO (Non orienté objet), c’est encore une fois sur le cursus de développement que reposera cette assertion. Nous pouvons singer l’héritage, soit, mais comment garantir que l’objet ancêtre est initialisé avant l’objet fils à chaque création ?

Parce que tu as écrit la fonction de création d'un objet en faisant en sorte qu'elle initialise (donc crée) les ancêtres avant de créer l'objet final, par exemple en appelant les fonctions de création des objets ancêtre avant de procéder à l'initialisation de l'objet fils.

J’espère vous avoir convaincu que les deux ne sont pas antinomiques, mais certainement pas équivalent en terme de régression et de sécurité du code.

Toutes les applications que je connais qui buggent sérieusement sont écrites en utilisant des langages objet... donc la "sécurité" de ce genre de chose me paraît être un argument plus que malhonnête en 2007. C'est comme dire que Java est sûr... faux, archi-faux, car du moment que tu peux "initialiser" des références à des objets par null, comment garantir que ton application ne se prendra pas un lamentable NullPointerException dans les dents ?

Franchement, si on connaissait un langage sûr, ça se saurait : même des langages comme Haskell ne sont pas sûrs, car si ils sont robustes à l'exécution, les programmes Haskell (ou fonctionnels) fonctionnent selon un logique voulant un code parfois très serré, difficile à lire (ça, c'est le côté pervers de l'abstraction) et à maintenir.

[gorgonite]

Le segment de données ne peut jamais être écrit, donc la fonction pointée reste toujours la même.

faux, faux et archi faux, on peut faire tout plein de trucs dynamiquement... c'est sale, illisible et peu portable, mais ça marche (testé et approuvé )

[InOCamlWeTrust]

Genre quoi ?

[Caine]

C'est plutôt le contraire : simuler un objet (une structure) comportant ses méthodes (des pointeurs de fonctions) et ses attributs (ses champs de données autres que les fonctions), c'est très facile. L'héritage est aussi très facile, en autorisant un objet (une structure) d'avoir un lien (un pointeur en C) vers son objet ancêtre (sa structure ancêtre).

Tu as bien lu ce que j'ai écris? Dans la POO, l'objet contient intrinsèquement ses méthodes et ces attributs. Il est donc plus facile den garantir la cohérence. D'ailleurs, j'ai bien indiqué qu'il était facile de simuler ce comportement mais certainement pas avec la même cohérence.

Dans un langage NOO, le type ne contient qu’un lien vers ses méthodes au mieux. Et si d’aventure tu veux un attribut simulant lui-même un autre objet, tu auras un pointeur là encore.

La POO sert à améliorer la maintenance, que tu es des contre exemples ne signifie en rien que la POO est un échec. J’ai vu autant de programmes mal codés dans les 2 courants de pensée.

Ben non, car même en C les fonctions ont un type de données... et dans les langages fonctionnels, encore plus.

Oui, et lors de l’évolution du logiciel, tu peux tout à fait remplacé par mégarde le pointeur sur une fonction par un pointeur sur une fonction de signature égale.

Non, c'est l'édition de liens dynamique (rien à voir avec les DLL, n'est-ce pas !).

Je ne vois pas pourquoi tu me parle de DLL, ça n’a rien à voir. Dans un langage procédural, le type de donnée ne contient que des pointeurs. Dans une classe, l’objet contient le code de sa méthode. Bon, chipotons un peu, l’objet contient en réalité un pointeur référencé via une table de fonction MAIS le programmeur ne met pas son nez dans ce mécanisme depuis l’extérieur dans des conditions normales de programmation.

Non, c'est tout à fait faisable en programmation traditionnelle.

Non, tu ne pourra jamais garantir qu’une erreur de programmation ne viendra pas invalidé le comportement de l’ancêtre sauf en OO.

Le segment de données ne peut jamais être écrit, donc la fonction pointée reste toujours la même.

Archi faut, comment tu crois qu’on simule le polymorphisme avec un pointeur de fonction. La fonction pointée est déterminée à l’exécution pas à la compilation. Rien n’empêche de changé la fonction pointée, même avec un pointeur const.

D'un autre côté, on ne raisonne pas au même niveau : la simulation d'un langage objet par un langage non objet est déjà an soi une implantation de ce langage objet : si l'implantation est bugée, tu auras forcément des problèmes à l'exécution... et si ton compilateur pour ton langage objet est buggé, tu auras aussi de sérieux problèmes...

La tu pousses un peu quand même !Tu me trouveras un langage sans bug en partant d’une version buguée du compilateur !

Parce que tu as écrit la fonction de création d'un objet en faisant en sorte qu'elle initialise (donc crée) les ancêtres avant de créer l'objet final, par exemple en appelant les fonctions de création des objets ancêtre avant de procéder à l'initialisation de l'objet fils.

NON ; parce que le langage objet t’oblige à définir un constructeur pour les types complexes.
En pascal objet ou Delphi, le souci n’existe pas, c’est le compilateur qui se charge d’ordonner les constructeurs/Destructeurs. Le développeur ne se concentre que sur chaque classe.

En C++, tu ne peux pas crée un objet dérivé et oublié d’appeler son constructeur ! Ca ne compilera pas.

Syntaxe du style ClasseDerivee :: constructeur : constructeur (bal bla).

SI tu omets l’appel du constructeur ancêtre, erreur de compilation.

Toutes les applications que je connais qui buggent sérieusement sont écrites en utilisant des langages objet... donc la "sécurité" de ce genre de chose me paraît être un argument plus que malhonnête en 2007.

Je n’ai pas dit que la POO est un dogme qui résout tout. J’ai dit vers quel but elle tend. La POO a résolut en partie certains problèmes et en a amené d’autres. Le plus difficile étant le choix de la visibilité de la classe la plus ancêtre.

C'est comme dire que Java est sûr... faux, archi-faux, car du moment que tu peux "initialiser" des références à des objets par null, comment garantir que ton application ne se prendra pas un lamentable NullPointerException dans les dents ?

Je ne suis pas fan du Java et là je suis sur le c ?l ! On peut faire une telle connerie ? Je suis resté vague, mais dans son approche la POO est un principe de programmation et les langages implémentent différemment ses concepts. Parce qu’un seul langage a introduit une erreur de conception, tu jettes tout les langages OO sans comparer leur implémentation de l’OO ? Moi non, dans la plupart de ceux que je maîtrise, bons nombres d’erreurs basiques de la programmation traditionnelle sont bannies. Mais d’autres erreurs sont aussi possibles.

Franchement, si on connaissait un langage sûr, ça se saurait : même des langages comme Haskell ne sont pas sûrs, car si ils sont robustes à l'exécution, les programmes Haskell (ou fonctionnels) fonctionnent selon un logique voulant un code parfois très serré, difficile à lire (ça, c'est le côté pervers de l'abstraction) et à maintenir.

Je n’ai jamais dit qu’il y avait un langage infaillible, bien que depuis que j’apprends Anubis…
Quelque soit le langage, la méthode de programmation et le programmeur, un problème mal compris ou mal posé donnera un logiciel de mauvaise qualité ; la dessus on est d’accord.