Discussion :

[souviron34]

J'ai l'impression que cette histoire de niveau d'abstraction est vécu comme un méchant coup de sabre alors que pour moi, c'est juste une caractéristique. Sans a priori positif ou négatif...

Pas du tout, mais c'est toi-même qui dit :

Pour moi, l'objet est un niveau d'abstraction supplémentaire par rapport au procédural. Une évolution

Ce que nous disons, c'est que non ce n'est pas un niveau d'abstraction supplémentaire..... C'en est un autre, sans plus...

Ce n'est ni plus ni moins abstrait...

Et ce n'est pas une "évolution", dans le sens darwinesque... Comme on l'a dit plus haut, c'est une autre vision de la même chose...

L'un n'est pas meilleur que l'autre, ni plus abstrait.

Certaines problématiques se prêtent plus à une vision qu'à une autre, certains programmeurs sont plus à l'aise avec une vision qu'avec une autre. SANS PLUS...

Normalement, on devrait arriver à faire la même chose...

Après, comme mentionné par el_slapper, cela dépend des contraintes de maintenabilité, du nombre de "choses" à maintenir (plus d'objets ou plus de fonctionalités ?) , sur quelle durée, avec quelles contraintes ?



Disons pour répondre à ton dernier point que nous - les plus vieux - sommes particulièrement sensibles sur ce point car depuis 15 ans nous voyons des gens sortis des cours (et des recruteurs) nous assuer qu'en deors de l'objet point de salut. .On a un petit peu dépassé le stade où l'objet était un Dieu et le reste de la m.rde, mais ça reste encore pas mal... (la fin de ton premier post en est encore une preuve). Que vous soyez formés et appréciez ces langages et paradigmes, c'est bien. Que vous répandiez "la bonne parole" en énonçant des contre-vérités ("Par contre, il n'est pas possible (ou au moins très compliqué) de faire de l'objet dans un langage qui n'est pas prévu pour.") teintées d'une pointe de supériorité ('Pour moi, l'objet est un niveau d'abstraction supplémentaire par rapport au procédural. Une évolution") est un mauvais service à vous rendre, et à vous-même et aux gens (jeunes en particulier) qui lisent ces forums....

[fatbob]

Oupla, mais je ne sors pas des cours.
Je n'ai certes pas ton expérience mais ça fait tout de même 20 ans que je programme dont 13 en SSII (j'en ai 45).
J'ai fait de la programmation procédurale pendant une dizaine d'années puis je suis passé à l'objet petit à petit depuis le début de ce millénaire.

Quand tu dis "contre vérité" j'aimerais bien savoir comment tu gères la question du polymorphisme ou de l'héritage en C ou en php4.

[souviron34]

Quand tu dis "contre vérité" j'aimerais bien savoir comment tu gères la question du polymorphisme ou de l'héritage en C ou en php4.

Si tu avais lu les pointeurs donnés tu aurais vu par exemple en page 2 de celui sur [Débat] modèles full OO et sources de données, est-ce un mythe? des exemples donnés par moi (post #21 et post #22), ainsi que par un autre intervenant (post 24) répondant à tes questions ..

Cela répondait à :

Je vais te poser une question qui à mon avis fait la différence entre POO et pas POO.
Tu cites l'exemple d'un objet Messager et d'un objet CentreDeTri qui tous les deux transmettent un courrier. Dans la version POO, nous sommes d'accord que ces 2 classes pourraient hériter d'une même classe (ou interface) parente qui exposerait une méthode TraiterCourrier() dans son contrat. Un objet tiers qui voudrait simplement envoyer un courrier sans se soucier des détails de l'expédition pourrait juste manipuler un objet du type de la classe parente qu'on lui passerait, et grâce au polymorphisme le bon traitement serait appliqué : par messager ou par centre de tri. On aurait alors une bonne maintenabilité du système puisque pour étendre notre gamme de modes d'expéditions, il suffit de créer une nouvelle classe implémentant le contrat TraiterCourrier() et d'en passer une instance à l'objet qui souhaite envoyer un message. Pas besoin de "casser" le code de la classe appelante ni de la classe de base.

Est-ce que la même chose serait possible dans le cas de fonctions statiques CentreDeTri_prendreCourier() et Messager_prendreCourier() et du code "procédural" que tu décris ? Si oui, et je veux bien savoir comment, je considère que c'est de l'orienté objet (ou du fonctionnel, à la limite).

Qui adressait et l'héritage et le polymorphisme...

[fatbob]

Je dois reconnaitre que c'est pas mal... Ca donnerait presque envie de se remettre au C :-)

[souviron34]

Je dois reconnaitre que c'est pas mal... Ca donnerait presque envie de se remettre au C :-)

Tu comprends un peu pourquoi certaines attitudes ou phrases nous fontt un peu ...bouillir ??

C'est pas compliqué, c'est astucieux, ça se met dans une biblothèque, on n'a pas à dupliquer le code à chaque fois, c'est souple, et ça existe depuis.. plus de 30 ans....

[fatbob]

Que certaines attitudes ou phrases font bouillir, je le vois.
Par contre, je pense qu'il y a un peu de sensibilité que je ne pensais pas heurter là dedans car je n'ai jamais douté que tout est faisable en C.

D'ailleurs, je ne doute pas non plus que tout est faisable en assembleur. Et quand on voit l'astuce de certains algorithmes en assembleur sur les sites genre celui ci : https://projecteuler.net/ , on ne peut que tirer son chapeau.

Après, j'ai encore de quoi débattre sur le sujet sous le coude mais effectivement, cela nécessiterait d'être face à face. Un forum n'est pas assez réactif et amène à pas mal de malentendus.

Je tiens juste à ce qu'une chose soit claire : même si je dis "niveau d'abstraction supplémentaire" ou "évolution", cela ne signifie pas "supériorité".
En premier lieu parce que la supériorité ne peut être définie que par rapport à un repère donné. Un langage de "plus haut niveau" ne veut pas dire un "meilleur langage" à tout point de vue.
En terme de concision de code, je pense que python est supérieur à java.
En terme de rapidité d'exécution, C est supérieur à python.
Mais assembleur est supérieur à C.
Ca ne signifie pas qu'en terme de lisibilité, assembleur soit supérieur à python.

D'autre part, je ne parle pas d'évolution au sens darwinesque mais évolution dans le sens "on ajoute une couche a un existant", ie : le champ sémantique des langages procéduraux est inclus dans le champ sémantique des langages objet. Le contraire n'est pas vrai. On peut créer des implémentations qui permettent d'obtenir des mécanismes similaires mais ce n'est pas natif.
Cela n'induit en rien un classement de valeurs d'un champ sémantique par rapport à un autre.
D'ailleurs, si c'était vraiment darwinesque, C aurait disparu, depuis le temps que l'objet existe.

[Mais j'arrête là, je sens que je repars pour une couche mais comme dit plus haut, un forum n'est pas adapté].

Tu vois ça comme des niveaux d'abstraction différents, soit. Ce n'est pas faux dans la mesure où, tous ces langages permettant de tout faire, c'est surtout la conception qui va jouer sur le résultat.

[souviron34]

Après, j'ai encore de quoi débattre sur le sujet sous le coude mais effectivement, cela nécessiterait d'être face à face. Un forum n'est pas assez réactif et amène à pas mal de malentendus.

Quand tu veux (sauf que je sais pas où tu es)

c'est surtout la conception qui va jouer sur le résultat.

Absolument...

C'est bien pour ça qu'au dessus on disait ce qu'on disait

La conception OO n'est pas liée à l'usage d'un langage objet, et par conséquent les notions de maintenabilité, lisiblité, adéquation, rapidité de codage , etc, sont strictement indépendantes du paradigme choiisi, mais dépendent essentiellement de la conception...