Que devient la programmation OO ? - Page 2

nitro :
En terme de langage, Java 5 réduit nettement l'écart avec C#, et c'est plutôt bien.

Certes, mais y a encore pas mal de trucs en moins (propriétés, conversions personnalisées, redéfinition d'opérateurs...)

J2EE ?

Quesoft
:

Kevin Kofler :
D'ailleurs, c'est affreux, l'API du Java. Pas mal de trucs qui se font en un appel de fonction en C se font en 3 créations d'objets et une dizaine d'appels de méthodes en Java. Travailler avec les dates par exemple. C'est immonde. Et en plus, là où il y avait des interfaces simples, elles ont été deprecated en faveur d'interfaces immondes (par exemple, on est maintenant obligé de passer par un objet GregorianCalendar pour convertir des dates en chaînes de caractères et vice-versa - je comprends qu'ils veuillent gérer d'autres types de calendriers, mais à ce moment-là, il faut prévoir un calendrier par défaut, parce que voir tous les programmes charger des objets GregorianCalendar, c'est débile, d'autant plus que les programmes ont tous GregorianCalendar codé en dur, alors c'est moins adaptable à d'autres calendriers, pas plus...).

Je pense que sur un PC moderne, même sur un P133, ont peut se permettre le tradeoff (facilité d'entretien et de modification VS rapidité d'exécution et taille), du moins pour un langage compilé. Sur TI68K, je t'accorde qu'un API comme celui du JDK est mal adapté. Avec celui du Moka, j’ai tenté de faire un compromis entre rapidité d’exécution, taille et similitude avec l’API de Java. Je crois avoir réussi pour la rapidité, qui est acceptable, mais il y a encore place à l’amélioration pour la taille …
Tout ça pour dire qu’effectivement, sur plate-forme TI on a pas les mêmes considérations que sur PC.

Sauf que ta reponse est totalement à côté de la plaque (en plus du fait que je ne suis pas d'accord, mais c'est une autre histoire...): là, ce n'étaient pas du tout des considérations d'efficacité, mais justement d'utilisabilité du point de vue du programmeur! Tu trouves plus simple de construire 3 objets et d'appeler plusieurs méthodes sur chacun que d'appeler une fonction, toi?

squalyl^2 :
char buffer[80]; scanf ("%s", buffer);

C'est faux! Correct:
char buffer[81];
scanf ("%80s", buffer);

Et la glibc propose une solution tout aussi courte et sans le problème des buffers de taille fixe:
char *buffer;
scanf ("%as",&buffer)

Comme quoi on n'a pas besoin de programmation orientée objet pour éviter les buffers de taille fixe, on peut très bien s'en sortir en C. C'est juste la librairie standard C qui est très vieille par endroits.

pardon j'ai oublié le null

Le vrai truc c'est que nous oublions tous que la TI est un système embarqué, très peu fait pour la POO.

squalyl^2 :
pardon j'ai oublié le null

Tu as surtout oublié la restriction de taille dans le scanf!

nitro :
Le C# est un standard ECMA et ISO, dont il existe plusieurs compilateurs autres que ceux de Microsoft. Il existe notamment deux implémentations libres : Mono et DotGNU.

Il semble que c'est vrai. Je ne le savais pas. Cependant, le standard est récent, il est venu après Visual Studio .NET. Ça reste quand même une invention de l'empire du mal ... Un genre de PL/I Microsoft Mais c'est bon à savoir, je vais pouvoir en refaire sans avoir de problème de conscience ...

nitro :
Des machines virtuelles .NET il y en a plusieurs, pour différentes plateformes. X86, PowerPC, S390 et SPARC sont supportés en JIT, et on peut ajouter HPPA, StrongARM, IA-64, Alpha et Mips en interpréteur.

Je savais qu'il y avait des projets pour créer des machines virtuelles sur d'autres plates-formes, mais c'est bon de savoir qu'il y a des implémentations existantes.

nitro :
T'as pas l'air de t'être renseigné suffisamment toi...

Effectivement, j'étais mal renseigné. Les specs ne sont pas propriétaire, puisqu'il existe un standard.

Bah .Net tourne sous WinCE, donc forcément, c'est multi-plateforme

Kevin> Faudrait juger sur autre chose qu'un seul exemple de situation.
J'aimerais bien vraiment connaître les tenants et les aboutissants des paradigmes impératif et orienté objet.

Tout d'abord, j’admets que mon post dont il était question n'était pas clair.

Pollux
:

Quesoft :
Vrai. En fait, faille de sécurité, j'irais pas jusque là ... D'un autre côté, le prog C peut planter si on écrit après le buffer - et à la limite on pourrait exploiter cette faille pour exécuter du code, c’est vrai.

Ou comment se contredire en deux phrases...

C’est contradictoire en effet, je m'en rends compte maintenant. Je voulais dire par là qu'il était possible de corriger la situation, que ce problème n'était pas inhérent au langage.

Pollux
:

Il est plus proche du Java que du C++ dans son implantation du paradigme, même si il est beaucoup plus similaire au C++ que le Java.

Ou comment se contredire en une phrase (bon, je veux bien que pour celle-ci tu aies mal choisi tes mots)

Cette fois, je m’exprime mal, mais je ne me contredis pas. La syntaxe pour instancier et manipuler les objets, la déclaration des méthodes, les classes du C# ressemblent au Java, plus qu’au C++. Cela ne l’empêche pas de ressembler plus au C++ que le Java peut lui ressembler : il y a des namespaces, des énumération, etc. C’est comme Java VS Objective C VS C++. Objective C est un langage qui est, comme le C++, un superset du C i.e., que l’on peut faire du C, on n’est pas forcé d’utiliser les fonctionnalités OO. À la base, il est plus proche du C++ que le Java peut l’être. Pourtant, la syntaxe pour faire de l’OO ne ressemble en rien au C++, alors qu’il y a une certaine similitude entre celle du Java et du C++.

Moi tout ce que je vois dans les réponses postées dans ce topic, c'est que beaucoup de personnes parlent de java(et accessoirement .net) sans vraiment connaître de quoi il s parlent, ils le connaissent vaguement.

Les gens savent vaguement ce que Java propose, ce qu'est J2EE. Des personnes parlent sans savoir ce qu'est java 2 ou java 5, bref ca ne m'étonne pas d'entendre ici des absurditées! Au final il y a beaucoup de parlotes de la part de personnes qui connaissent mal le sujet et du coup peu de remarques pertinantes (à part Nitro )

Java 2 commence à partir de la version 1.2 jusqu'à la 1.4.2
Java 1 correspond en gros à la première génération de JDK (version de 1.0 à 1.1.18 et quelques)
Java 5 correspond à Java 1.5

J2EE c'est autre chose Neuroo, J2EE est une suite de librairies qui ont des fonctionnalités liées au développement d'applications d'entreprise: EJB, JMS, JSP, SERVLET, on appelle ça la pile J2EE, en général c'est la base des conteneurs (serveurs) J2EE tels que JBOSS, JONAS, etc...
J2EE n'est pas une version différente de J2SE mais une suite de librairies qui viennent en ajout.

Je ne vais pas m'étendre la-dessus, ce n'est pas le but.

Utiliser la POO avec un langage de plus haut niveau que du C++ comme du Java, avec une suite de librairie complète doit permettre de se focaliser au niveau d'une application plus sur l'organisationnel que sur le code, puisque les implémentations d'algos sont en général déjà fournis.


squalyl^2 :
char buffer[80];
scanf ("%s", buffer);

Moi je trouve ca génial!!!

Au fait dans Java il n'y a pas de générique, d'autoboxing, de redéfinition d'opérateurs et tout le tra lala avant la version 1.5, car ca favorise les erreurs et malentendus sur la signifaction du code. Ce n'est que mon point de vue. Même si je trouve que ces améliorations sont les bienvenues

Kevin Kofler :
Sauf que ta reponse est totalement à côté de la plaque (en plus du fait que je ne suis pas d'accord, mais c'est une autre histoire...): là, ce n'étaient pas du tout des considérations d'efficacité, mais justement d'utilisabilité du point de vue du programmeur! Tu trouves plus simple de construire 3 objets et d'appeler plusieurs méthodes sur chacun que d'appeler une fonction, toi?

Non, pour cet exemple, c'est vrai que ce qu'offre le C est plus simple pour le programmeur. Mais c'est pas le cas pour d'autres choses, lorsque le programme ne se contente pas de demander un seul input de l'utilisateur. Le fait que l'API de Java soit ou non convivial pour cette tâche ne veut pas dire que les langages le OO soient systématiquement moins convivial que les langages procéduraux. Je fais référence à mon exemple de la programmation fenêtrée, entre autres.

Kevin Kofler :
Comme quoi on n'a pas besoin de programmation orientée objet pour éviter les buffers de taille fixe, on peut très bien s'en sortir en C. C'est juste la librairie standard C qui est très vieille par endroits.

Ça j'ai jamais osé l'affirmer, j'aimes bien l'OO, comme je l'ai déjà dit, mais la présence d'une faille ou non dans un API n'a pas de lien avec tel ou tel paradigme... C'est sûr qu'avec l'encapsulation, c'est plus facile de faire un API sécurisé et stable et qui permet des modifications majeures de l'implémentation sans qu'il n'y ait d'impact sur les programmeurs.

alexis :
Moi tout ce que je vois dans les réponses postées dans ce topic, c'est que beaucoup de personnes parlent de java(et accessoirement .net) sans vraiment connaître de quoi il s parlent, ils le connaissent vaguement.

Les gens savent vaguement ce que Java propose, ce qu'est J2EE. Des personnes parlent sans savoir ce qu'est java 2 ou java 5, bref ca ne m'étonne pas d'entendre ici des absurditées! Au final il y a beaucoup de parlotes de la part de personnes qui connaissent mal le sujet et du coup peu de remarques pertinantes (à part Nitro )

C'est vrai que l'on devrait se renseigner d'avantage, et c'est sympathique de votre part de nous partager l'étendu de votre savoir sur le sujet, mais même si l'on ne connaît peut être pas les specs de Java ou du C# par coeur, ça ne rend pas automatiquement notre opinion caduc

alexis :
Au fait dans Java il n'y a pas de générique, d'autoboxing, de redéfinition d'opérateurs et tout le tra lala avant la version 1.5, car ca favorise les erreurs et malentendus sur la signifaction du code. Ce n'est que mon point de vue. Même si je trouve que ces améliorations sont les bienvenues

Ouch... la version 1.5 doit emmener beaucoup de choses. Surcharge des opérateurs : c'est de plus en plus C++ !

Ils ont ajouté la notion de propriétés au moins ?

Euh attention, pas de confusion, dans java 1.5 pas de redéfinition d'opérations, mais il y a des génériques et de l'auto-boxing, le type enum, et bien d'autres choses...

alexis :
Euh attention, pas de confusion, dans java 1.5 pas de redéfinition d'opérations, mais il y a des génériques et de l'auto-boxing, le type enum, et bien d'autres choses...

Désolé, de la façon dont j'avais lu votre précédent post, j'avais l'impression que c'était le cas.

oué, j'ai pas été très clair.

Ce me fait bizarre qu'on me dise "vous"... dis "tu"

Quesoft, je sais pas si on te l'a déjà dit, mais tu es la seule personne sur tout yN à vouvoyer les gens

[mode=chieur]

alexis :
Au fait dans Java il n'y a pas de générique, d'autoboxing, de redéfinition d'opérateurs et tout le tra lala avant la version 1.5, car ca favorise les erreurs et malentendus sur la signifaction du code. Ce n'est que mon point de vue. Même si je trouve que ces améliorations sont les bienvenues

Ben faudrait savoir : y a 5 ans les programmeurs étaient trop cons pour comprendre du code avec des génériques, et depuis ils sont devenus intelligents ?
J'y crois pas une seule seconde, soit ils ont mal évalué l'utilité de la chose dans les premières versions, soit c'était trop compliqué à implémenter et ils ne pouvaient le faire que maintenant, soit c'est effectivement une mauvaise chose et c'est une erreur de l'avoir mis dans la dernière version. Dans les 3 cas, ils ont foiré au moins une chose, donc tu ne peux pas être d'accord avec eux sur toute la ligne (et personnellement je penche pour un mix des deux premières solutions, heureusement que MS est là pour qu'ils se bougent le cul ^^)
[/mode]

EDIT : rha, cross

(java a bien 10 ans)

(ca prouve que ca marche)

alexis: j'ai dit ca en posant une qn pke je ne connais pas...

Quesoft
:

Pollux
:

Il est plus proche du Java que du C++ dans son implantation du paradigme, même si il est beaucoup plus similaire au C++ que le Java.

Ou comment se contredire en une phrase (bon, je veux bien que pour celle-ci tu aies mal choisi tes mots)

Cette fois, je m’exprime mal, mais je ne me contredis pas. <snip>

Oui t'inquiètes j'avais compris, je te taquinais

Sasume
:

Pollux :
Moi tout ce que je dis c'est que Java est mal foutu, ce qui n'est pas nouveau

Tu parles du langage ou de l'API ?
Perso, le langage je le trouve plutôt bien comparé au C++.

Nan bon c'est à moitié un troll

Evidemment si ton point de comparaison c'est C++, t'as la garbage collection en plus et toutes les conséquences que ça peut avoir... Mais y a pas mal de trucs assez décevants, surtout avant java 5 (rien que l'absence de génériques, c'est n'importe quoi ), par exemple l'absence de propriétés, qui est un peu aberrante à mon sens : le fait que "size" soit effectivement un membre de la classe ou qu'il soit au contraire une méthode est avant tout un détail d'implémentation, et ce serait bien que ces détails n'apparaissent pas dans le code qui utilise ces fonctions... Après on peut dire que "oui mais les propriétés pourraient en fait contenir du code qui fait plein de trucs méchants", mais une propriété n'a pas à avoir d'effets de bords "visibles", c'est tout... (et de toute façon en l'absence de propriété, ce serait un appel de méthode, ce qui n'est pas du tout mieux)

Et puis le peu que j'ai pu voir de l'API m'a pas semblé hyper-bien foutu -- cela dit je ne nie pas qu'il y a pleins de libs en java et que c'est ça qui fait tout son intérêt ^^

Je n'ai pas énormément d'expérience pour juger, mais en tout cas, moi je trouve que le langage java est vraiment mieux foutu que le C++. Le truc vraiment bien par rapport au C++, c'est qu'on ne passe pas son temps à jongler entre références et pointeurs. Et puis le GC aussi, c'est vraiment bien pratique.

Sinon, c'est quoi les propriétés par rapport à un attribut classique ?

alexis :
oué, j'ai pas été très clair.

Ce me fait bizarre qu'on me dise "vous"... dis "tu"

C'est noté

En ce qui concerne les génériques en Java je ne connais pas l'étendue de leur capacités, je ne crois pas qu'on puisse faire tout ce qu'on fait en c++. Il faudrait que je me renseigne, je n'ai pas encore vraiment étudié toutes les nouveautés de java 1.5

En tout cas en C# ils ont effectivement enlevé les paramètres de type "entier" pour ne laisse que ceux de type "type".

Sasume
: Je n'ai pas énormément d'expérience pour juger, mais en tout cas, moi je trouve que le langage java est vraiment mieux foutu que le C++. Le truc vraiment bien par rapport au C++, c'est qu'on ne passe pas son temps à jongler entre références et pointeurs. Et puis le GC aussi, c'est vraiment bien pratique.

Ah oui nan mais je suis bien d'accord qu'un GC est utile (et le fait de ne plus avoir de pointeurs au sens propre est une conséquence immédiate de l'absence de GC). D'ailleurs, <troll> c'est pas parce que Caml est garbage-collecté que ça en fait un bon langage </>
En tout cas perso je trouve la syntaxe de Java bcp plus lourde que celle du C++, c'est assez pénible... (et Ruby pawa, pour le coup )

Enfin bon il faut voir aussi que ce qui freine énormément l'adoption de Java/C# pour l'instant, c'est que la VM est très lourde (surtout dans le cas de Java) et c'est long à télécharger (surtout dans le cas de C#, où en plus personne ne l'a). Ce qui fait que c'est surtout utilisé dans des gros serveurs en entreprise...

Sinon, c'est quoi les propriétés par rapport à un attribut classique ?

Je ne sais pas ce que tu entends par attribut, mais par propriété j'entends simplement du sucre syntaxique pour transformer "bla.y = bla.x.length" en "bla.setY(bla.getX().getLength())"

Pollux :
Ben faudrait savoir : y a 5 ans les programmeurs étaient trop cons pour comprendre du code avec des génériques, et depuis ils sont devenus intelligents ? [...]

C'est la même chose avec les propriétés, comme tu le soulignes plus loin. Je pense qu'ils ne sont toujours pas supportés dans le Java 5.

Ne vous trompez pas : j'aime le Java et c'est le langage en lequel j'ai le plus aimé programmer ... Mais ça ne veut pas dire que j'approuve tous ses features. C'est une question de goûts rendu là ...

Pollux
:

Sinon, c'est quoi les propriétés par rapport à un attribut classique ?

Je ne sais pas ce que tu entends par attribut, mais par propriété j'entends simplement du sucre syntaxique pour transformer "bla.y = bla.x.length" en "bla.setY(bla.getX().getLength())"

Oh, je n’avais pas vu la question.

Ce que j'entend par propriété, et c'est un concept dans l'UML aussi je crois, c'est un attribut qui a des accesseurs i.e. qui est encapsulé. En ce sens, il y a évidemment des propriétés en Java, mais le langage, contrairement au C#, Delphi, etc. ne supporte pas qu’on les référence de façon transparente : on est obligé d’appeler les méthodes directement.

Par exemple, si j’ai une propriété Nom, en Java j’utilise par convention la méthode monObjet.setNom(‘’Son nom’’) pour lui donner une valeur et monObjet.getNom() pour la récupérer. Ce que je veux dire par support des propriétés c’est la possibilité de référencer une propriété comme un attribut : monObjet.nom = ‘’Son nom’’ …

Je présume que les concepteur du Java voyaient ça comme quelque chose d’obscure et de mélangeant pour le programmeur.

À mon avis, les deux façons de procéder permettent l’encapsulation, mais le support des propriété est agréable pour le programmeur (c’est subjectif, j'en suis conscient).

C'est d'ailleurs la même chose en C++. La "solution" est que toutes les conventions de programmation C++ et Java disent de ne jamais mettre une variable en public, mais de toujours utiliser des accesseurs (getter, setter), même s'ils sont triviaux (return var; ou this->var=var;), afin de permettre de mettre des accesseurs plus complexes plus tard.

Kevin Kofler :
C'est d'ailleurs la même chose en C++. La "solution" est que toutes les conventions de programmation C++ et Java disent de ne jamais mettre une variable en public, mais de toujours utiliser des accesseurs (getter, setter), même s'ils sont triviaux (return var; ou this->var=var;), afin de permettre de mettre des accesseurs plus complexes plus tard.

Une bonne apologie de l'encapsulation

Bien d'accord avec kevin pas de variable en public sauf cas particulier

cf: la librairie swt propose un grand nombre de variables en accès public pour la rapidité de la simplicité, mais ce sont des variable qui ont un rôle simple de manière général sur lesquelles on ne peut pas se planter, du genre donner le nombre de colonnes dans un gridLayout

De plus pour la rapidité les classes qui ont besoin d'accéder à différentes variables n'imposent pas de mettre les variables en public , on peut très bien limiter l'accès en mettant un accès friendly ou en protected.