Que devient la programmation OO ? - Page 1

Bonjour,

Par le passé, plusieurs programmeurs ont signifié leur désir de disposer d'un langage orienté-objet pour la plate-forme 68K.

Plusieurs projets ont vu le jour pour supporter différent langages OO : le java avec Moka, bien sûr, mais aussi le C++ et même Objective C si je ne me trompe pas.

Qu'arrive-t-il de tous ces projets ? Est-ce que seul Moka est fonctionnel ? Est-ce que des développeurs programment en suivant le paradigme OO, que ce soit en l'un des langages cités plus haut où encore en C directement (ce qui est très éreintant, pour l'avoir fait) ?

Est-ce que, comme l’a déjà soulevé une certaine sommité en C, les langages OO n’ont pas d’utilité sur cette plate-forme ?

Pour ma part, je compte développer mes futurs programmes en OO et je vais continuer à mettre à jour Moka, parce que c’est divertissant. Cependant, j’aimerais bien savoir s’il y a d’autres programmeurs qui préfère l’approche OO aux trucs tricky en C pour être en mesure d’arriver aux mêmes résultats (types de donnés abstraits, pointeurs vers des fonctions, utilisation de stdarg.h, etc.) …

Je préfère développer dans du langage Objet quand j'ai le choix (je trouve Java génial malgrés ces performances d'exécution). Mais je ne développe plus pour Ti...

Quesoft :
Est-ce que, comme l’a déjà soulevé une certaine sommité en C, les langages OO n’ont pas d’utilité sur cette plate-forme ?

sommité , LOL
il n'a pas entierement tord. La Ti est quand même un contexte "embarqué", donc il faut "optimiser".
Mais p-e que j'essayerais un jour d'en faire, et surtout de regarder tes sources (si tu les a mis a dispo), pour voir comment tu fais.

objective C sur ti lol...

hibOu :
Je préfère développer dans du langage Objet quand j'ai le choix (je trouve Java génial malgrés ces performances d'exécution). Mais je ne développe plus pour Ti...

Quesoft :
Est-ce que, comme l’a déjà soulevé une certaine sommité en C, les langages OO n’ont pas d’utilité sur cette plate-forme ?

sommité , LOL
il n'a pas entierement tord. La Ti est quand même un contexte "embarqué", donc il faut "optimiser".
Mais p-e que j'essayerais un jour d'en faire, et surtout de regarder tes sources (si tu les a mis a dispo), pour voir comment tu fais.

Sans vouloir vanter Moka, il est quand même assez efficasse en taille et en rapidité pour être viable sur TI.

Le overhead est de seulement 697 octets (un prog C avec un main vide fait 303 octets, un prog Moka en fait 697). On est loin du 5K que parlait Kevin pour l'équivalent C++... Le seul problème c'est que, bien que la syntaxe soit du Java, Moka ne supporte pas toutes les specs de ce langage.

Si vous aimez la programmation OO, c'est une option viable je crois.

Quesoft
: Cependant, j’aimerais bien savoir s’il y a d’autres programmeurs qui préfère l’approche OO aux trucs tricky en C pour être en mesure d’arriver aux mêmes résultats (types de donnés abstraits, pointeurs vers des fonctions, utilisation de stdarg.h, etc.) …

Les programmeurs qui préférent un langage OO aux hacks grossiers pour faire de l'OO en C, je pense bien que tu peux me mettre dans ta liste. Mais ce n'est pas ce qui compte. Ce que je préfère (et je pense que c'est le cas pour la plupart des programmeurs C, pratiquement tous à part les développeurs GTK ou GNOME), c'est du C pas du tout OO. C'est tellement plus simple et plus efficace. Les OOistes: pourquoi voulez-vous tout mettre dans des "méthodes" et pas tout simplement dans des fonctions? Ça sert à quoi? Des langages OO, j'en ai faits et j'en fais toujours (C++, Java, VB, un peu de Delphi). Mais tout ce que je peux faire en ces langages, je peux le faire en C, avec de simples fonctions. À la limite des structures, mais pas d'histoires de pointeurs de fonctions dans les structures pour simuler des classes etc. Et même en les langages OO, j'ai souvent une classe bidon qui ne sert qu'à rassembler un paquet de fonctions, voire des fonctions normales si le langage le permet (C++, VB, Delphi).

Kevin Kofler
:

Quesoft
: Cependant, j’aimerais bien savoir s’il y a d’autres programmeurs qui préfère l’approche OO aux trucs tricky en C pour être en mesure d’arriver aux mêmes résultats (types de donnés abstraits, pointeurs vers des fonctions, utilisation de stdarg.h, etc.) …

Les programmeurs qui préférent un langage OO aux hacks grossiers pour faire de l'OO en C, je pense bien que tu peux me mettre dans ta liste. Mais ce n'est pas ce qui compte. Ce que je préfère (et je pense que c'est le cas pour la plupart des programmeurs C, pratiquement tous à part les développeurs GTK ou GNOME), c'est du C pas du tout OO. C'est tellement plus simple et plus efficace.

Il me semble que, bien souvent, une solution OO est plus facile à implémenter. Entre autres, il quand j'ai implémenté un API pour développer des applications fenêtrées, cela semblait un choix naturel.

Kevin Kofler :
Les OOistes: pourquoi voulez-vous tout mettre dans des "méthodes" et pas tout simplement dans des fonctions? Ça sert à quoi? Des langages OO, j'en ai faits et j'en fais toujours (C++, Java, VB, un peu de Delphi). Mais tout ce que je peux faire en ces langages, je peux le faire en C, avec de simples fonctions. À la limite des structures, mais pas d'histoires de pointeurs de fonctions dans les structures pour simuler des classes etc.

Il me semble, qu’à part SmallTalk si je ne me trompe pas, tous les langages OO permettent des méthodes statiques, qui sont un équivalent des fonctions. C'est sûr que si tu ne programmes pas en orienté-objet, un langage qui supporte le paradigme ne te sers à rien ...

Kevin Kofler :
Et même en les langages OO, j'ai souvent une classe bidon qui ne sert qu'à rassembler un paquet de fonctions, voire des fonctions normales si le langage le permet (C++, VB, Delphi).

On peut fort bien programmer en procédural traditionnel avec un langage objet (à part peut-être en SmallTalk, qui est assez extrémiste – absolument tout est un objet : il n’y a pas de type primitif et même les instructions sont des objets), mais j’admets que lorsque l’on fait ainsi, un langage dont l’API repose entièrement sur des objets (comme le Java) peut être désagréable à utiliser.

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...).

pour convertir les date en chaines de caractères tu utilises les classe de type format:
exemple: new SimpleDateFormat("EEEEE, dd MMMMM yyyy").format(new Date());

C'est pas compliqué c clean, je ne vois pas le problème, je ne trouve pas qu'il y ait quoi que ce soit de barbare j'utilise java tous les jour, et ca me convient parfaitement.
Comme tu le vois on utilise pas ici la classe abtraite Calendar, ni meme gregorianCalendar qui correspond au calendrier occidental, et qui permet non pas d'afficher des dates, mais faire des calculs de date par exemple:

Calendar c = new GregorianCalendar(Locale.FRANCE);
c.add(Calendar.MONTH, -1);
SimpleDateFormat spf = new SimpleDateFormat("EEEEE, dd MMMMM yyyy");
System.out.println(spf.format(c.getTime()));

Tout ca de tete, trop du pour afficher la date...

Comme tu peux le voir, GregorianCalendar est hérité de la classe Calendar, donc on peut très bien affecter un object de type GregorianCalendar à une variable de type Calendar et donc utiliser la superclasse Calendar.

De plus on peut obtenir une instance neutre d'un object calendar de la manière suivante: Calendar c = Calendar.getInstance();

la classe Date sert de passerelle entre plusieurs classe et a la compatibilité, Calendar sert au calcul de date, et SimpleDateFormat sert au formatage de date...




C juste que tu ne connais pas suffisemment java, comme tu pourrais dire la même pour moi de tigcclib...

[Hors-Sujet]Au fait, je voudrais savoir, toi qui connais linux sur le bout des doigts, tu en penses quoi de Mono, sais-tu si on peut développer avec mono pour PocketPC? => le CompacFramework est-il utilisable sur mono[Hors-Sujet]

Au fait la POO sur ti, hum, peut-être pas, je ne suis pas sur que ce soit viable, enfin à chacun son point de vue, il faut rappeler que c'est du 12mhz et 500ko de mémoire voir 2mo c un peut juste sauf si c'est du compilé et qu'il n'y a pas besoin de runtime ...

alexis :
pour convertir les date en chaines de caractères tu utilises les classe de type format: exemple: new SimpleDateFormat("EEEEE, dd MMMMM yyyy").format(new Date());

Mais là tu as utilisé new Date, pas une date concrète... Pour affecter une date concrète à ta date, tu es obligé de passer par un Calendar.
Et déjà, devoir créer un objet SimpleDateFormat rien que pour formater une date, c'est idiot. Pourquoi ne peut-on pas utiliser directement quelque chose comme Date.format ou Date.toString? Ce serait beaucoup plus logique.

C'est pas compliqué c clean, je ne vois pas le problème, je ne trouve pas qu'il y ait quoi que ce soit de barbare j'utilise java tous les jour, et ca me convient parfaitement.

Je n'ai pas dit "barbare" (=sale), j'ai dit "immonde" (et je veux dire par là: beaucoup trop complexe, limite inutilisable).

Compare à strftime(buffer,100,"%A, %d %B %Y",timeptr);. Pas besoin de créer un objet poubelle, et le format est plus court aussi.

Comme tu peux le voir, GregorianCalendar est hérité de la classe Calendar, donc on peut très bien affecter un object de type GregorianCalendar à une variable de type Calendar et donc utiliser la superclasse Calendar.

Et ça change quoi? Tu es toujours obligé de créer un objet de type GregorianCalendar...

De plus on peut obtenir une instance neutre d'un object calendar de la manière suivante: Calendar c = Calendar.getInstance();

Mais ça ne sert à rien si on a des jours-mois-ans à convertir en dates. (Du moins si je me rappelle bien. Je suis content de ne pas avoir à toucher aux manipulations de dates en Java actuellement, j'en ai marre...)

la classe Date sert de passerelle entre plusieurs classe et a la compatibilité, Calendar sert au calcul de date, et SimpleDateFormat sert au formatage de date...

Et c'est débile. C'est beaucoup plus compliqué que nécessaire.

alexis
: [Hors-Sujet]Au fait, je voudrais savoir, toi qui connais linux sur le bout des doigts, tu en penses quoi de Mono, sais-tu si on peut développer avec mono pour PocketPC? => le CompacFramework est-il utilisable sur mono[Hors-Sujet]

Moi? Je n'ai pas touché à Mono. J'ai fait du Java dans des projets à l'université, mais j'ai horreur de ce langage, alors le C# (qui lui ressemble beaucoup), ça ne me tente pas. Quand il y aura des programmes intéressants en Mono, je téléchargerai peut-être les runtimes.

"Mais là tu as utilisé new Date, pas une date concrète... Pour affecter une date concrète à ta date, tu es obligé de passer par un Calendar."

Bien sur, si tu veux utiliser une date qui n'est pas la date courante, car new Date() renvoie la date courante.


Pour ma part, je trouve l'utilisation des date très aisée en java, elle est très complète.

Ce que tu reproches c'est la séparation des opérations en plusieurs étapes et objets, mais c'est la que les programmeurs objects y trouvent les avantages, le truc c'est que tu n'aimes pas la POO.

Je me sers tous les jours de la gestion des dates au travail et je trouve la manipulation de date très aisée Comme quoi ca dépend de l'expérience de chacun.

Bah disons que l'orientation objet, quand ça s'applique bien c'est très sympa, ça fournit une organisation et une modularité qu'on n'a pas sans orientation objet ; dans le genre exemple bateau, il y a tout simplement les classes conteneur genre "map<string,set<int> >". Là, il y a clairement à chaque fois un objet privilégié (le conteneur), et qui n'a rien à savoir de ce qu'il contient à part savoir le copier. Niveau modularité, c'est parfait ; niveau concision, l'orientation objet est très puissante (m["hello"].contains(3), à comparer avec set_of_int_contains(map_from_string_to_set_of_int_item(m,"hello"),3) en C).

Malheureusement ça n'est pas toujours aussi clair, et si une méthode dépend de N paramètres, privilégier un et un seul de ces paramètres n'est pas forcément le plus logique : par exemple new SimpleDateFormat(bla).format(new Date()) -- moi ça m'aurait paru plus logique de faire new Date().format(new SimpleDateFormat(bla)) (un peu comme new Date().toString(), par exemple...) Et le problème avec un certain nombres de langages orientés objets, c'est qu'en plus ce choix de paramètre privilégié est fortement lié à l'implémentation : exemple, si la classe Date n'a pas la méthode format() en builtin, ma seule solution est de mettre ça dans une autre classe et de faire autre_classe.format(date) plutôt que date.format(autre_classe)

ca marrant ca m'a pas l'air plus simple car pour moi vous mélangez les rôles: simpledateformat est une classe de formatage de date. A quoi ca sert de faire une classe qui intègre tout c con apres on s'en sort plus dans les fonctionnalités, chaque classe son rôle et c'est très bien comme ca.

De toute facon la poo et la non poo sont deux mondes différents et les deux visions du développement se respectent

alexis :
Au fait la POO sur ti, hum, peut-être pas, je ne suis pas sur que ce soit viable, enfin à chacun son point de vue, il faut rappeler que c'est du 12mhz et 500ko de mémoire voir 2mo c un peut juste sauf si c'est du compilé et qu'il n'y a pas besoin de runtime ...

Bien sûr, pour la plate-forme TI, l'interprété, ou ce qui roulle sur machine virtuelle n'est pas viable à mon avis ... Je me souviens des programmes Waba (un vrai interpréteur byte code) qui marchaient très bien, mais étaient plus lents que tu basic (où, à tout le moins, d'une vitesse similaire).

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.

moi ce que je remarque en toute objectivité hein:

char buffer[80];
scanf ("%s", buffer);

--->

try {
String buffer = (new BufferedReader(new InputStreamReader( System.in) ) ).readline();
} catch (Exception E) {}

squalyl^2 :
moi ce que je remarque en toute objectivité hein:

char buffer[80];
scanf ("%s", buffer);

--->

try {
String buffer = (new BufferedReader(new InputStreamReader( System.in) ) ).readline();
} catch (Exception E) {}

¨
Ça fait tellement longtemps que j'ai pas fait de 'vrai' java que j'avais oublié ça !

Mais, dans un programme d'une certaine taille, on n'a qu'à instancier un seul BufferedReader. Pas besoin de gérer de buffers, contrairement au C, alors c'est quand même pas si dramatique que ça. Dans une application fenêtrée, client-serveur, le JDK avec son API graphique et ses RMI est très convivial. De toute façon, c'est une particularité du langage Java, non pas de l'OO.

En Moka :
String str = System.readLine() ; // Retourne un objet String

C'est moins OO que d'instancier un InputStreamReader pour gérer un flux d'entrée, puis un BufferedReader pour le lire, je sais bien ...

Hum, moi ce que je vois c'est un code avec une faille de sécurité et sans gestion d'erreur, et un autre qui est clean de ce point de vue.

J'allais le dire Menfin bon ça n'empêche pas que Java est excessivement verbeux, cf Console.ReadLine() en C#...

alexis
: pour moi vous mélangez les rôles

Euh, j'espère que t'es pas en train de me mettre dans le même panier que Kevin
Moi tout ce que je dis c'est que Java est mal foutu, ce qui n'est pas nouveau

nitro :
Hum, moi ce que je vois c'est un code avec une faille de sécurité et sans gestion d'erreur, et un autre qui est clean de ce point de vue.

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.

En C comme en Moka, la détection des conditions d'exception est la responsabilité du programmeur.

Pollux :
J'allais le dire Menfin bon ça n'empêche pas que Java est excessivement verbeux, cf Console.ReadLine() en C#...

C# qui est d'ailleurs OO. 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. J'en ai pas fait beaucoup, juste essayé quelques trucs, mais ça a l'air bien (grr ... dommage que ce soit un truc et propriétaire et de l'empire du mal). Par contre, c'est compilé pour une machine virtuelle ... qui n'est pas multi plates-formes (je sais qu'il y a un projet de port par contre). Bravo : the worst of both world ! Le compilateur JIT semble être efficasse au moins.

Quesoft
: grr ... dommage que ce soit un truc et propriétaire et de l'empire du mal

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.

Par contre, c'est compilé pour une machine virtuelle ... qui n'est pas multi plates-formes

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.

Bravo : the worst of both world !

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

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...

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)

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++.

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

5 ? C'est pour quand ?

Mais ca ne vaut pas C#

./27> y'a un mois.
Java 1.5 renommé en java 5

Ah

Mais alors qu'est-ce que c'est Java 2 ?