pour la dernière phrase, peut-être un peu, mais sur le reste non.
J'ai en fait raté d'autres éléments de la phrase que je soulignais, l'implication "plus près de l'expérience humaine" => "potentiellement moins complexe que l'approche procédurale". En dehors du fait que le lien logique ne me parait pas établi, le mot "potentiel" laisse en fait beaucoup de marge d'interprétation.
A mon sens, l'approche objet est une autre façon d'aborder ce qu'on appelait "modularité" auparavant. Évidemment, il n'est pas question de remettre en cause l'intérêt de la modularisation dans la conception et le développement, mais d'interroger l'affirmation selon laquelle la POO serait moins complexe que l'approche procédurale. En fait, la question est de savoir dans quelle mesure le "potentiel" cité ci dessus est réalisé.
Franchement, au vu des questions fleurissant dans les forums sur les problématiques purement objet, il me semble qu'on peut se poser la question.
On notera aussi que par rapport au C++ (qui reste un langage emblématique de la POO), Java a supprimé certains concepts et en a simplifié d'autres. Quelles sont les raisons de ces choix conceptuels ? Il me semble que c'était la trop grande complexité de certains concepts, ce qui tendrait à indiquer que l'approche objet est pas si évidente que ça.
L'approche objet est utile, voire même agréable dans certains cas, mais, à mon avis, la qualité de l'architecture du code et de la modélisation de structures/base de données/objets dépendent plus des qualités d'abstractions des concepteurs/développeurs que des facilités des différents langages. Pour le dire autrement, le langage vient dans un second temps et permet l'implémentation plus ou moins rapide de telle ou telle approche, mais n'est pas un élément déterminant : un bon langage ne débouche pas forcément sur des bons programmes, une bonne approche ne fait pas forcément des bons développeurs. (oui, bon, là, j'enfonce un peu des portes ouvertes ... :)
[^] # Re: heu ...
Posté par gaaaaaAab . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
pour la dernière phrase, peut-être un peu, mais sur le reste non.
J'ai en fait raté d'autres éléments de la phrase que je soulignais, l'implication "plus près de l'expérience humaine" => "potentiellement moins complexe que l'approche procédurale". En dehors du fait que le lien logique ne me parait pas établi, le mot "potentiel" laisse en fait beaucoup de marge d'interprétation.
A mon sens, l'approche objet est une autre façon d'aborder ce qu'on appelait "modularité" auparavant. Évidemment, il n'est pas question de remettre en cause l'intérêt de la modularisation dans la conception et le développement, mais d'interroger l'affirmation selon laquelle la POO serait moins complexe que l'approche procédurale. En fait, la question est de savoir dans quelle mesure le "potentiel" cité ci dessus est réalisé.
Franchement, au vu des questions fleurissant dans les forums sur les problématiques purement objet, il me semble qu'on peut se poser la question.
On notera aussi que par rapport au C++ (qui reste un langage emblématique de la POO), Java a supprimé certains concepts et en a simplifié d'autres. Quelles sont les raisons de ces choix conceptuels ? Il me semble que c'était la trop grande complexité de certains concepts, ce qui tendrait à indiquer que l'approche objet est pas si évidente que ça.
L'approche objet est utile, voire même agréable dans certains cas, mais, à mon avis, la qualité de l'architecture du code et de la modélisation de structures/base de données/objets dépendent plus des qualités d'abstractions des concepteurs/développeurs que des facilités des différents langages. Pour le dire autrement, le langage vient dans un second temps et permet l'implémentation plus ou moins rapide de telle ou telle approche, mais n'est pas un élément déterminant : un bon langage ne débouche pas forcément sur des bons programmes, une bonne approche ne fait pas forcément des bons développeurs. (oui, bon, là, j'enfonce un peu des portes ouvertes ... :)