[Débat] C++ vs Java

Version imprimable

Voir 40 message(s) de cette discussion en une page

20/02/2012, 13h52
hegros
Citation:

Envoyé par Luc Hermitte

Le problème fondamental, c'est que comparer selon l'égalité deux voitures (entités) n'a strictement aucune sens!

Je ne suis pas sûr de bien comprendre. Est-ce que ce que tu dis ne reviens pas à dire que cela n'a aucun sens de faire un test d'égalité autre que sur des types primitifs ?

Et que donc surcharger l'opérateur == en C++ (et je suppose que tu l'entends pas seulement pour le C++) n'a pas de sens sauf pour les types primitifs et donc par extension qu'un test égalité n'est valide que pour le domaine de l’algèbre, l'arithmétique et les mathématiques de manières générales ? Ou alors c'est spécifique aux entités voiture ?

J'ai quand même du mal à généraliser et accepter aussi facilement cette assertion lorsqu'on s"intéresse à un domaine autre que les maths.

Est-ce que c'est une erreur d'écrire (et de quelle nature/type)
Code:

1 2 3 4 if(EmissionCO2MarqueXModelY == EmissionCO2MarqueSModelV) { cout << "ces 2 modèles émettent la même quantité de co2" ; }
ou dans sa variante Java
Code:

1 2 3 4 if(EmissionCO2MarqueXModelY.Equals(EmissionCO2MarqueSModelV)) { Println.WriteLine("ces 2 modèles émettent la même quantité de co2"); }
PS : oui j'espère bien qu'en regardant la vidéo cela m'aidera à mieux vous comprendre.
20/02/2012, 15h04
Luc Hermitte

Une émission d'ozone n'est pas une entité. C'est une valeur.
Quant à deux mesures ben ... leurs quantités sont comparables, pas vraiment les mesures, qui ont une date de mesure typiquement que l'on ne voudra pas voir intervenir dans la comparaison d'égalité. Non ?

Je dis qu'il ne sert à rien de vouloir tester l'égalité entre deux entités. Deux mouches, deux voitures, deux enfants. L'égalité n'a aucun sens sur les entités.
Ils peuvent avoir des attributs qui eux sont comparables. Deux références vers des entités peuvent pointer vers la même entité, on s'intéresse à l'identité d'une entité, pas à son état global.
20/02/2012, 16h02
hegros

Citation:

Envoyé par Luc Hermitte

Une émission d'ozone n'est pas une entité. C'est une valeur.
Quant à deux mesures ben ... leurs quantités sont comparables, pas vraiment les mesures, qui ont une date de mesure typiquement que l'on ne voudra pas voir intervenir dans la comparaison d'égalité. Non ?

peut être que oui et peut être d'autres éléments encore.

Dans l'absolu ne peut-on pas ramener toute entité à un ensemble de valeurs ? Puisqu'une entité c'est construit à partir de types valeurs

Citation:

Envoyé par Luc Hermitte

Je dis qu'il ne sert à rien de vouloir tester l'égalité entre deux entités. Deux mouches, deux voitures, deux enfants. L'égalité n'a aucun sens sur les entités.

Ils peuvent avoir des attributs qui eux sont comparables. Deux références vers des entités peuvent pointer vers la même entité, on s'intéresse à l'identité d'une entité, pas à son état global.

je comprends un test d'égalité d'entités sur des attributs bien-sûr et/ou leurs états sinon sur quoi d'autres ? Sur les adresses mémoires cela me semble trop bien peu intéressant et moins vaste que les domaines/métiers.

Ne pourrait-on pas tester l'égalité par exemple entre 2 workflows identiques s’exécutant en parallèle ou en distribué? Le test se ferait sur les états de ces machines.

Ne pourrait-on pas tester l'égalité sur 2 molécules ? Le test se ferait sur son état (gazeux, liquide,...)

Il doit y avoir encore quelque chose qui m'échappe sur ce que tu entends par égalité entre entité (pas encore vu la vidéo en même temps :-) )
20/02/2012, 16h33
Luc Hermitte

Mon expérience me fait dire que la dichotomie entité/valeur, aussi simpliste soit-elle s'applique à 80-90% des cas que l'on rencontre.
Et cela me simplifie grandement la vie. Pas de copie à supporter. Pas de test d'égalité à mettre en œuvre quand j'identifie mes entités. Et encore, même parmi la famille des copiables, toutes n'ont pas à supporter la comparabilité.

Ce n'est pas forcément la video qui parlera le mieux de cela même si Stenapov n'est pas innocent dans l'arrivé de cette dichotomie en C++.
Ceci en parle à la limite: http://akrzemi1.wordpress.com/2012/0...lue-semantics/

PS: ce n'est pas parce que l'entité est aussi définie avec un ensemble de valeurs qu'elle devient comparable au sens égalité avec une autre entité -- et que cela nous soit utile d'une quelconque façon.
20/02/2012, 19h42
koala01

Citation:

Envoyé par hegros

Dans l'absolu ne peut-on pas ramener toute entité à un ensemble de valeurs ? Puisqu'une entité c'est construit à partir de types valeurs

Justement, non: une entité se construit sur base des services que l'on attend d'elle, et ce sont ces services qui vont déterminer les valeurs qu'elle utilisera ;)

Quelque part, la POO "institutionnalise" l'encapsulation dans le sens où, justement, on va commencer par s'intéresser (d'abord et avant tout! ) aux services que l'on attend d'un type donné, et que ce sont ces services qui détermineront les données que l'on utilisera comme membre ;)

Quand on envisage les choses de cette manière, on en vient déjà à se dire que, finalement, l'usage d'accesseur se limite au maximum et est souvent relié à des types particulièrement simples, et que l"usage de mutateur est encore beaucoup plus rare (car de nombreuses modifications seront en réalité effectuées au sein des fonctions correspondant aux services attendus ;))

Citation:

je comprends un test d'égalité d'entités sur des attributs bien-sûr et/ou leurs états sinon sur quoi d'autres ? Sur les adresses mémoires cela me semble trop bien peu intéressant et moins vaste que les domaines/métiers.

Tout dépend, bien sur de si tu considère que ton égalité te permet d'identifier de manière unique et non ambigue une entité parmi toutes les autres ou si tu considère que c'est un test d'équivalence ;)

L'égalité se basera sans doute, plus que sur une adresse (qui peut toujours être réutilisée par un autre objet) sur un attribut discriminant unique (renvoyé, par exemple, par la fonction membre id() ;) ) alors que l'équivalence se basera sur "un ensemble" (plus ou moins complexe :D ) d'attributs non forcément discriminants ( ex : la marque, le modèle, la couleur et la motorisation d'une voiture :D)

C'est pour cela que je m'insurge contre l'héritage systématique avec une super classe Object et contre toute fonction demandant un Object en argument (dont la fameuse fonction Equals :D ) car il y a peu de chances que tu dispose, au niveau de la super classe, des moyens te permettant de récupérer les différents attributs sans passer par un transtypage ( cast :D ) ou par un double dispatch ;)

Ceci dit, quand il s'agit de comparer deux entités, l'égalité a généralement pour but de pouvoir dire "oui, oui, c'est bien de cet objet là que l'on parle et de nul autre " ;)

Citation:

Ne pourrait-on pas tester l'égalité par exemple entre 2 workflows identiques s’exécutant en parallèle ou en distribué? Le test se ferait sur les états de ces machines.

Ce n'est malheureusement, pas parce que deux workflows présentent, à un instant T, un état identique qu'ils sont identiques!!!

Dans le meilleur des cas, le fait qu'ils présentent deux états identiques indiquerait sans doute un "point de confluence", un point de controle permettant de les synchroniser, par exemple ;)

Citation:

Ne pourrait-on pas tester l'égalité sur 2 molécules ? Le test se ferait sur son état (gazeux, liquide,...)

La comparaison de leur seul état ne suffirait sans doute pas :aie:

Une molécule d'oxygène et une molécule d'azote peuvent, par exemple, toutes les deux se trouver dans un état similaire (gazeux ou liquide), mais leur réaction par rapport à leur environnement (et inversement) sera totalement différente en fonction que l'on aura effectivement une molécule de l'un ou de l'autre (un simple exemple : leur passage de l'état gazeux à l'état liquide se fera à une température différente ;))

Citation:

Il doit y avoir encore quelque chose qui m'échappe sur ce que tu entends par égalité entre entité (pas encore vu la vidéo en même temps :-) )

Si il existe, le test d'égalité entre deux entités doit être suffisamment discriminant pour permettre d'identifier de manière unique et non ambigüe le fait que l'on a bien affaire à l'une d'elles en particulier, à l'exception de toute autre

La manière d'arriver à ce résultat dépend, bien évidemment, du type de l'entité à tester et des services que ce type fournit ;)
20/02/2012, 21h34
hegros

Citation:

Envoyé par koala01

Tout dépend, bien sur de si tu considère que ton égalité te permet d'identifier de manière unique et non ambigue une entité parmi toutes les autres ou si tu considère que c'est un test d'équivalence ;)

Identifier de manière unique et non ambigu une entité parmi toutes les autres me semblent bien basique (je vois encore cela comme un test de plomberie informatique sans valeur puisque cela se résume en gros à tester l'égalité de 2 guid) et à que peu de valeur relatif à un domaine, c'est donc le test d'équivalence qu'il faut plutôt considérer ici.

Citation:

Envoyé par koala01

C'est pour cela que je m'insurge contre l'héritage systématique avec une super classe Object et contre toute fonction demandant un Object en argument (dont la fameuse fonction Equals :D ) car il y a peu de chances que tu dispose, au niveau de la super classe, des moyens te permettant de récupérer les différents attributs sans passer par un transtypage ( cast :D ) ou par un double dispatch ;)

Comme tu l'avais déjà fais remarquer il est possible de surcharger Equals avec autant de type abstrait ou pas par rapport à ce qui nous intéresse. En pratique se serait se limiter que de ne pas surcharger Equals. En tout cas cela permet d'éviter le transtypage barbare bien que cela puisse engendrer pleins de surcharges en fonction de la qualité de la conception. Remarque aussi que comme l'a fais remarquer Luc c'est dû au fait que cela ne soit pas une méthode paramétrable du genre Equals<T>(T t) auquel cas ce problème se poserait moins ou pas du tout.

Citation:

Envoyé par koala01

Ceci dit, quand il s'agit de comparer deux entités, l'égalité a généralement pour but de pouvoir dire "oui, oui, c'est bien de cet objet là que l'on parle et de nul autre " ;)
Ce n'est malheureusement, pas parce que deux workflows présentent, à un instant T, un état identique qu'ils sont identiques!!!

Dans le meilleur des cas, le fait qu'ils présentent deux états identiques indiquerait sans doute un "point de confluence", un point de controle permettant de les synchroniser, par exemple ;)
La comparaison de leur seul état ne suffirait sans doute pas :aie:

C'est justement là que je ne suis pas. Ce test d'égalité (équivalence) est à définir par les personnes du domaine. S'ils décident qu'un workflow d'inscription universitaire dans la ville X est égal à un workflow d'inscription universitaire dans une ville Y parce que les 2 universités sont dans l'état "En cours d'inscription" et que ces 2 derniers workflow ne sont pas égaux à celui de la ville Z parce que ce dernier est dans l'état "Fermé pour travaux" , il n'y a à priori rien de tordu la dedans. Il est évident ici que l'on ne cherche pas à comparer des objets dans le sens informatique du terme mais dans un sens du domaine.

Je pense comprendre maintenant que pour vous un test d'égalité n'est pas un test d'équivalence ou en tout cas que c'est un test de ce que je nommerais d'après ma compréhension actuelle un test de plomberie qui reviendrait grossomodo à tester l'égalité d'un guid de 2 objets.

Si tel est le cas cela revient à ma remarque précédente : la surcharge de l'opérateur d'égalité n'aurait du sens que dans le domaine mathématique (type valeur) alors que d'après kisitomomotene c'est contradictoire avec la notion d'équivalence en maths. Me trompe je ?
21/02/2012, 00h20
zaventem

Pour ma part, affirmer que deux objets sont égaux signifie qu'ils sont interchangeables, que d'un point de vue logique (après, l'implémentation est un autre aspect qui a ses propres contraintes) je peux utiliser l'un ou l'autre sans que cela ne change quoi que se soit. Ainsi, une méthode paramétrique Equals<T> me parait incongrue, une pomme ne sera jamais égale à une poire. Elles peuvent être semblable, avoir certains aspects identiques mais elles ne seront jamais égale.

Pour continuer sur ton exemple de workflow, il me semble une fois de plus que de leur donner la responsabilité de déterminer s'ils sont égaux entre eux me semble une erreur de conception. Dans le cas trivial où leur identité ne dépendrait que de l'état dans lequel l'université se trouve est réalisable mais l'énoncé même me semble indiquer la raison pour ne pas le faire: leur équivalence est fonction d'un élément qui ne dépend pas d'eux.
21/02/2012, 02h44
koala01
Citation:

Envoyé par hegros

Identifier de manière unique et non ambigu une entité parmi toutes les autres me semblent bien basique (je vois encore cela comme un test de plomberie informatique sans valeur puisque cela se résume en gros à tester l'égalité de 2 guid) et à que peu de valeur relatif à un domaine, c'est donc le test d'équivalence qu'il faut plutôt considérer ici.

Cela peut aussi bien être un guid qu'un ensemble de valeurs distinctes...

Si l'on fait le rapprochement avec une base de donnée, une clé primaire peut très bien être composée, chaque partie prise séparément pouvant être représentée par des occurrences multiples, alors qu'il y a contrainte d'unicité sur l'ensemble représenté par ces valeurs ;)

Java fournit la méthode hash via sa classe Object, qui rend ce genre de service, mais, encore une fois, le fait de n'avoir pas de classe parent "obligatoire" permet de se passer ce cette possibilité si l'on souhaite utiliser une manière plus adaptée au domaine envisagé ;)

Ainsi, nous pourrions très bien avoir une classe personne pour laquelle nous créerions l' opérateur d'égalité proche de
[code=c++]bool Personne::operator == (Personne const & second) const
{
return name() == second.name() && firstName()==second.firstName();
}[/code=c++] et il pourrait parfaitement y avoir un sens (afin de permettre le tri, par exemple) à y trouver un opérateur "less" proche de
Code:

1 2 3 4 5 6 bool operator Personne::operator < (Personne const & second) const { return name() < second.name() || (name() == second.name() && firstName < second.firstName() ); }
(si, du moins, on considère que le nom et le prénom sont suffisant pour identifier une personne de manière unique et non ambigüe, ce qui n'est pas vraiment le cas ;))

voir, pourquoi pas, les foncteurs équivalents ;)

Citation:

C'est justement là que je ne suis pas. Ce test d'égalité (équivalence) est à définir par les personnes du domaine. S'ils décident qu'un workflow d'inscription universitaire dans la ville X est égal à un workflow d'inscription universitaire dans une ville Y parce que les 2 universités sont dans l'état "En cours d'inscription" et que ces 2 derniers workflow ne sont pas égaux à celui de la ville Z parce que ce dernier est dans l'état "Fermé pour travaux" , il n'y a à priori rien de tordu la dedans. Il est évident ici que l'on ne cherche pas à comparer des objets dans le sens informatique du terme mais dans un sens du domaine.

Si ce n'est que l'état "en cours d'inscription" sera l'état du futur élève alors que l'état "fermé pour rénovation" sera l'état de l'établissement :D

On pourrait donc, effectivement, envisager qu'un futur élève "en cours d'inscription" dans l'université X soit transféré à l'université Y pour une raison quelconque, dont, par exemple, le fait que l'université X ne soit pas en mesure de recevoir d'élève suite à son état "d'incapacité" ;)

C'est là que tu te rendra compte que l'état d'un ou de plusieurs objet(s) servira, au final, de point de jonction entre plusieurs workflow, permettant, selon le cas, une synchronisation ou un passage d'information (voir d'objets plus ou moins complexe :D )de l'un à l'autre

Il faut, bien sur, adapté sa conception à l'aspect métier envisagé, mais, ce qui doit primer d'abord et avant tout, c'est les principe de conception OO, sous peine d'avoir un canard à trois pattes au final ;)

Citation:

Je pense comprendre maintenant que pour vous un test d'égalité n'est pas un test d'équivalence ou en tout cas que c'est un test de ce que je nommerais d'après ma compréhension actuelle un test de plomberie qui reviendrait grossomodo à tester l'égalité d'un guid de 2 objets.

On peut dire cela de cette manière ;)

Et c'est là qu'interviennent les notions de sémantique d'entité et de sémantique de valeur ;)

Il peut exister plusieurs instances différentes d'un type ayant sémantique de valeur dont le test d'égalité s'intéresse à la valeur représentée par le type envisagé (1 reste égal à 1 ou "bonjour" reste égal à "bonjour", quel que soit le nom de la variable ou l'adresse mémoire à laquelle il se trouve :D) alors qu'il n'existera jamais qu'une seule instance clairement identifiée (de manière unique et non ambigüe :D) d'un type ayant sémantique d'entité.

Le type Integer en java, par exemple, est un type ayant sémantique de valeur, alors qu'une classe "CompteBancaire" aura classiquement sémantique d'entité:

Ton compte bancaire étant identifié par un numéro unique et non ambigu, tu est certains que, dés que tu récupères un compte bancaire portant le numéro du tien que tu n'agis pas sur celui de ton voisin (ou de n'importe qui d'autre du pays).

Par contre, si le solde du compte est représenté par un entier, il se peut très bien que ton compte présente un solde identique à monsieur Machin qui habite Macapette les bains ;)

Une des grosses différence qu'il y aura entre les classes ayant sémantique de valeur et celles ayant sémantique d'entité, c'est que les classes ayant sémantique d'entité seront souvent composées par un (ou plusieurs) attribut(s) définitivement fixé(s) (ex: le numéro du compte) et un (ou des) attributs susceptible(s) d'être modifé(s) (ex: le solde du compte :D ) alors que toute modification que l'on pourrait apporter à un objet dont le type est une classe ayant sémantique de valeur aura pour résultat la création d'un nouvel objet, quitte à ce qu'il soit affecté à la variable qui représentait l'ancien ;)

Ainsi, la classe String (ou quel que soit le nom similaire) a typiquement sémantique d'entité:

Si tu ajoutes ou retires un ou des caractère(s) à une chaine de caractères, tu obtiens... une nouvelle chaine de caractères, quitte à ce qu'elle soit représentée par la variable qui représentait la chaine de caractères d'origine (grace à l'opérateur d'affectation) ;)

De plus, il est tout à fait possible d'avoir deux variables de type "chaine de caractères" présentant exactement la même valeur (et donc renvoyant "true" dans un test d'égalité) mais n'ayant rien à voir entre elles ;)

Citation:

Si tel est le cas cela revient à ma remarque précédente : la surcharge de l'opérateur d'égalité n'aurait du sens que dans le domaine mathématique (type valeur) alors que d'après kisitomomotene c'est contradictoire avec la notion d'équivalence en maths. Me trompe je ?

L'opérateur d'égalité peut parfaitement avoir un sens avec les types ayant sémantique d'entité, sous réserve d'attendre en argument au minimum une information correspondant à son "identifiant unique", ou permettant de l'obtenir ;)

Ainsi, en C++ nous pourrions très bien avoir
Code:

1 2 3 4 5 bool CompteBancaire::operator == (CompteBancaire const & second) const { return id() == second.id(); }
mais nous pourrions aussi avoir
Code:

1 2 3 4 bool CompteBancaire::operator == (TypeIdentifiant numeroCompte) const { return id() == numeroCompte; }
(où TypeIdentifiant représente le type qui aura été choisi pour représenter l'identifiant unique d'un compte bancaire ;))

Le problème dans l'histoire, c'est que, dans une très grande majorité des cas (à vrai dire, je cherche encore le cas dans lequel ce ne serait pas vrai :D ), Une classe dérivé respectant le LSP aura... sémantique d'entité (tu pourrais faire hériter CompeDepargne et CompteAVue de compteBancaire ou Client et Fournisseur de Personne, sans que cela n'enfreigne LSP ;)) alors que les classes ayant sémantique de valeurs n'ont généralement pas vocation à se retrouver dans une hiérarchie de classes:
la classe Couleur (pour changer un peu :D) a typiquement sémantique de valeur car
1. on peut retrouver la même couleur à différents endroits dans le code sans pour autant que ce soit toujours le même objet (que l'objet ne se trouve toujours à la même adresse mémoire, dirons nous ;))
2. La classe couleur n'a, a priori, besoin ni d'hériter de quoi que ce soit (en dehors de toute obligation faite par le langage s'entend) ni d'être dérivée en quoi que ce soit ;)
Bien sur, tu me diras, sans doute, que tu peux prévoir plusieurs types de couleurs (noir et blancs, tons de gris, RGB, RGBA, YUV et tous les autres), mais, si tu respecte LSP, étant donné qu'il n'y a pas vraiment de "propriété communes" entre ces différentes couleur et que, de plus, il n'y a pas vraiment de sens à faire cohabiter plusieurs de ces couleurs dans une même collection, il n'y a pas vraiment lieu de leur trouver une classe de base commune ;)

En C++, la classe couleur interviendrait sans doute dans une approche générique (comprend : comme argument de type dans une fonction ou une classe template ;))

Le gros avantage que l'on en tirerait, c'est que les classes template qui seraient "spécialisées" en fonction de ces couleurs n'auraient qu'une interface identique, mais resteraient sans lien direct (Truc<BlackAndWithe> restant totalement différent et indépendant de Truc<RGBA> ;)), à moins, bien sur, que la classe Truc n'hérite d'une classe non template ;)

En java, ou en tout autre langage basé sur une classe "Super Objet", il est impossible d'avoir des hiérarchies de classes "indépendantes" (car Truc <BlackAndWhite> peut parfaitement servir de classe de base :D ) et tu te retrouve donc avec une hiérarchie de classes beaucoup plus volumineuse (pense simplement au niveau auquel se trouverait Truc ou BlackAndWhiteColor dans la hiérarchie java :D )et donc, beaucoup plus difficile à faire évoluer de manière homogène, et sans interférence avec "l'existant" ;)
21/02/2012, 14h30
Luc Hermitte

Citation:

Envoyé par hegros

a- C'est justement là que je ne suis pas. Ce test d'égalité (équivalence) est à définir par les personnes du domaine. S'ils décident qu'un workflow d'inscription universitaire dans la ville X est égal à un workflow d'inscription universitaire dans une ville Y parce que les 2 universités sont dans l'état "En cours d'inscription" et que ces 2 derniers workflow ne sont pas égaux à celui de la ville Z parce que ce dernier est dans l'état "Fermé pour travaux" , il n'y a à priori rien de tordu la dedans. Il est évident ici que l'on ne cherche pas à comparer des objets dans le sens informatique du terme mais dans un sens du domaine.

b- Si tel est le cas cela revient à ma remarque précédente : la surcharge de l'opérateur d'égalité n'aurait du sens que dans le domaine mathématique (type valeur) alors que d'après kisitomomotene c'est contradictoire avec la notion d'équivalence en maths. Me trompe je ?

a- Franchement ? Qu'est-ce que cela peut bien nous faire que les deux workflows soient dans des états similaires ? À quoi ça sert ? AMA, à rien.
Et combien même, la similarité est sur quoi ? Un morceau de l'état (dynamique. tiens? c'est vrai.). Car égalité il n'y a clairement pas, chacun a une ville différente ; ne parlons même pas des gens en attente qui ne sont pas les mêmes, pas en même quantité, etc -- comme quoi on ne s'intéresse clairement pas à l'égalité des workflows, mais à un autre critère pour une comparaison donnée.

b- Non pas forcément. L'état peut être autre chose que mathématique. Ce peut être un tag (pour une machine à états, un gestionnaire de bookmarks/cercles/contacts), une chaine, ou même des truc plus compliqués.
21/02/2012, 14h55
Logan Mauzaize

Citation:

Envoyé par hegros

Mouais je ne suis pas expert Java mais qu'est-ce qui empêche d'avoir une vm écrite en Java 'compilé'.

Parce que Java n'est pas natif : tu ne peux pas faire de manipulation mémoire, ni faire des appels systèmes.
C'est toute la philosophie de la technologie (comprendre Langage + Plateforme).

Citation:

Envoyé par souviron34

je ne suis pas d'accord avec ton post : lorsqu'on compare, entre les Factory et les initialisations inutiles provoquées par les new, il y a beaucoup d'"overhead" inutiles générées par le C++.

+1 !

Citation:

Envoyé par souviron34

Je pense plus prosaiquement que comme le C++ a été poussé par les formations/universités et que les jeunes du début des années 2000 ne juraient que par le C++, en jetant aux oubliettes le C (pouah. C'est pas un langage objet) , un certain nombre d'industries ont basculé vers le C++ par manque de main-d'oeuvre et formation inadéquate des dirigeants de l'époque.

Étant issue de cette génération, je ne peux que plussoyer. D'ailleurs je me souviens même pas qu'on m'est signalé que tel code était du C et un autre du C++. C'est bien plus tard que j'ai appris la différence entre les deux.
Pour aller plus loin, même le C++ était déprécié. Sur 5 ans d'étude, le C++ n'aura eu sa place que la première année, ensuite Java à fond !

[MYLIFE]Pour information, j'ai fait un IUT et un IUP, les formations sont calées (et très légèrement ancitipées) sur les besoins des entreprises environ deux ans avant l'entrée de l'élève dans le cursus.[/MYLIFE]
Et Java a toujours généré plus d'emploi que C++. On pourrait discuter longtemps de pourquoi mais je pense qu'il y a un certains gains en productivité et son slogan "Compile once, run everywhere".
Pour le premier point, je pense notemment à sa légèreté dans la gestion des ressources. Pas besoin d'avoir des design complexes, de mettre des responsabilités, on peut tout faire à l'arrache et tout marche (à peu près). Tant pis si ce n'est pas nickel chrome. Redémarrer un serveur une fois par mois, ca coute moins cher qu'un seul jour/homme de développement...

Concernant le deuxième point, la portabilité que tu peux t'accorder en C++ s'arrête au source "annoté". Il faut en effet ajouter des instructions de pré-compilations pour avoir un source "multi-plateforme". Et impossible d'avoir un .o ou .so ou .dll portable. Sur les systèmes UNIX avec la gestion des dépendances, ca peut se gérer (et encore !) mais pour Windows t'es marron.
Et franchement reconstruire un produit pour pouvoir l'utiliser c'est tout de même assez "con" comme principe.

Citation:

Envoyé par souviron34

Mais pour en faire depuis 23 ans tout en n'étant pas un "systémique", je ne vois pas en quoi le C serait plus réservé aux drivers : je n'ai jamais écrit de driver de ma vie, et toutes les appls que j'ai faites sont "haut-niveau"..

+1, c'est comme dire que COBOL est reservé à la finance ...

Citation:

Envoyé par souviron34

Pour moi le C sert à faire des applis performantes, avec des facilités d'optimisation, dans un langage que tout scientifique comprend, comme le Fortran. Et avec un paradigme de fonctionalités, ce qui est très nettement plus correspondant à ce que pense un scientifique que le paradigme objet.

Je connais quasiment pas C++ (et encore moins le C) mais en quoi est-ce spécifique au C par rapport au C++ ?

Citation:

Envoyé par jabbounet

C et C++ sont parfaitement portable si tu as tu t'impose une certaine discipline que t'impose d'autres technos.

Tu n'obtiendras pas la même portabilité rien qu'au niveau des sources et absolument aucune au niveau binaire.

Citation:

Envoyé par jabbounet

Java peu ne pas être supporté par certains matériels spécifiques si aucune jvm n'a été porté sur ce type de palteforme, et si tu sors des standards tu peux avoirs soucis avec la porta comme pour les autres langage.
exemple utiliser des trucs dans java.sun.misc et ensuite devoir porter ton application sur une jvm non différente de celle de sun (oracle maintenant)

Le package java.sun.misc ne fait pas partie de l'API ...

Citation:

Envoyé par koala01

Peut etre me diras tu que c'est la grande force de java ou de C# que d'avoir su imposer ces restrictions arbitraires (je pense, entre autres, à l'interdiction de l'héritage multiple, mais pas seulement ;) )

L'interdiction de l'héritage multiple paraît assez naturelle car elle évite de nombreux problèmes d'utilisation, que cela n'ajoute finalement pas grand chose, ca clarifie le code et que ca simplifie/optimise la compilation et l'exécution. Si on met dans une balance, ca penche beaucoup plus en faveur de l'interdiction que l'autorisation.

Citation:

Envoyé par koala01

cela a pour conséquence de faire croire à certains concepteurs / développeurs / programmeurs qu'ils sont parfaitement compétants alors qu'ils sont d'une incompétence crasse!!!

Je dirai plutôt que tout le monde se prenne pour un "crack", que ca permet d'accéder plus facilement à la compétence de "développeur". Pas besoin de penser comme une machine pour coder, c'est tout de même appréciable. Ensuite la philosophie, c'est qu'en se libérant de la résolution de problèmes "bas-niveau" (comme l'allocation, la virtualité, passage par copie/référence), un développeur d'un langage de "haut-niveau", peut se concentrer sur des problèmes plus grands et plus complexes. Et ainsi un gain non négligeable en productivité.

Citation:

Envoyé par koala01

Il est assez frappant de constater que la réponse que la plupart des gens apportent à la question "quelle est la base de la programmation OO" et l'encapsulation, alors que la base de la programmation OO est en réalité... la subsituabilité (comprend : le fait qu'un objet de n'importe quel type héritant d'une classe de base puisse "passer pour" un objet de la classe de base elle-même).

On dit "polymorphisme" :zoubi:

Citation:

Envoyé par koala01

Le problème des langages comme Java, c'est qu'ils ont décidé de faire en sorte que tout objet créé héritera d'office d'une classe de base commune (Object).

Tu me demanderas sans doute où est le problème la réponse est simple : il est dans le fait que, du coup, il t'est tout à fait possible de demander de manipuler une pomme et une voiture de la même manière (en les considérant comme des Object) alors qu'il n'y a aucun point commun entre ces deux types particuliers.

Où est l'hérésie de dire que dans un langage objet tout est objet ?
Pour autant que je sache, je peux tous les deux les décrire, les toucher et les manipuler.

Citation:

Envoyé par koala01

Le deuxième problème, même s'il s'agit d'un cas d'utilisation rare, est qu'il devient impossible de décider de faire en sorte qu'un type particulier hérite de deux classes distinctes car cela impliquerait le fait que le type en question aurait deux représentations de la classe de base de ces deux classes distinctes.

Or, il n'y a aucune raison objective (hormis un problème de conception à la base) pour vouloir imposer une telle limite dans le paradigme OO ;)

Non ce n'est pas rare et c'est pourquoi il y a les interfaces. Le vrai problème c'est de déterminer le code à exécuter dans le cadre de l'héritage multiple (voir le problème du diamand).

Citation:

Envoyé par koala01

Enfin, le fait d'imposer le fait que tout soit d'office objet (que l'on doive créer un objet contenant la fonction principale) est en lui-même quelque part aberrant, car il n'y a strictement aucune raison d'interdire la création de fonction libres, étant donné que le paradigme OO utilise malgré tout le paradigme impératif ;)

Dans le paradigme objet, il n'y a pas de fonction et tout comportement est rattaché à un objet ... Java utilise le paradigme impératif uniquement pour décrire les comportements et ce n'est pas général à l'OO.

Pour te paraphraser :

Citation:

Envoyé par koala01

Malgré tout le respect que j'ai pour ~~lui~~toi, ~~Tovald~~tu n'as ~~jamais~~ rien compris au paradigme OO ~~et n'y comprendra sans doute jamais rien!!!~~...

Citation:

Envoyé par koala01

Si ce n'est qu'il n'y a pas forcément lieu de faire en sorte que toute chose puisse être clé dans une map, et il n'y a absolument aucune raison de permettre de comparer une pomme avec une voiture (même si, par défaut, c'est au niveau de l'adresse que la comparaison a lieu ;))

Une map permet de créer une association non structurelle entre deux objets, donc oui, c'est normal que tout puisse être clé d'une map ... C'est une forme simpifiée d'inversion de contrôle.

Citation:

Envoyé par koala01

Je n'ai pas dit que cela permet à une pomme d'avoir une fonction freine, j'ai dit que tu peux appeler les fonctions présentées par Object (essentiellement equals ) en ayant d'un coté une pomme et de l'autre une voiture...

Or, cela n'a strictement aucun sens ;)

Dans un monde abstrait, cela a du sens. Pense au tout-couillon jeu du Schmilblick (ou 20Q) !

Citation:

Envoyé par koala01

Mais, justement, pourquoi rendre cette hérésie possible :question:

Si tu te permet de juger un concept abstrait sur la base d'un exemple d'un monde ultra-limité, alors abandonnes la programmation ou contentes-toi de pisser du code ;)
Et pour autant que je sache, en C++, je peux comparer tous mes pointeurs ...

Citation:

Envoyé par koala01

Cela fait des années que l'on répète de ne pas le faire, et de préférer, au pire, le paradigme générique (voir des classes comme boost::any ;))

Pourquoi ne pas le faire si c'est nécessaire ? D'ailleurs tu fais comment un code générique si tu n'acceptes pas un point commun ?
D'ailleurs avec un nom comme boost::any, je vois pas trop la différence avec java.lang.Object ???
void* n'est ni plus, ni moins qu'un java.lang.Object sans comportement. Quand tu vois la part de code Java qui sont basés sur les méthodes de "base", tu te rends bien compte du temps gagné !

Citation:

Envoyé par koala01

Le problème, c'est qu'avec java, si tu te demande quel est le plus petit commun à deux classes, tu retomberas systématiquement sur Object, alors qu'en C++, tu restes libre de décider quel est ce plus petit commun (avec, il est vrai, le risque de partir sur un God Object equivalent ;))

Super si tu manipules des objets qui viennent de deux framework différents !

Citation:

Envoyé par koala01

Les fonctions et variables statiques ont déjà quelque chose d'aberrant quand on y pense!!!

Je te rassure ce sont biens des aberrations, mais en général on préfére le pragmatisme au conceptuel ...

Je corrige :

Citation:

Envoyé par koala01

Nous sommes dans un contexte dans lequel "tout est objet", et on nous dit que c'est une ~~fonction~~méthode qui ne dépend d'aucun ~~objet~~instance en particulier du type en question~~, mais qui est partagée par l'ensemble des objets et qui appartient pourtant à la classe!!!~~

Citation:

Envoyé par koala01

Car, même dans les cas tordus où l'on souhaiterait pouvoir faire hériter une classe de deux classes distinctes ayant la même classe de base, il est tout à fait possible d'éviter la duplication des données propres à cette classe de base

Dans le cas du diamand, car dans ce cas c'est l'appelant qui pourrait éventuellement déterminer s'il a plus besoin de faire avancer un avion (en l'air) ou un bateau (à l'eau) pour un hydravion. Mais qui décidera s'il veut juste faire avancer un véhicule ?
(Ok, l'exemple est bidon mais c'est l'idée).

koala01, je voudrais juste finir en m'excusant si tu le prends mal. Je n'ai rien contre toi mais tes remarques m'ont fait bondir ^^
21/02/2012, 15h35
adiGuba

Citation:

Envoyé par Nemek

Citation:

Envoyé par hegros

Mouais je ne suis pas expert Java mais qu'est-ce qui empêche d'avoir une vm écrite en Java 'compilé'.

Parce que Java n'est pas natif : tu ne peux pas faire de manipulation mémoire, ni faire des appels systèmes.
C'est toute la philosophie de la technologie (comprendre Langage + Plateforme).

Il est tout à fait possible d'avoir une JVM en Java ! C'est d'ailleurs un des objectif d'Oracle pour la JVM officiel (à long terme). On en a parlé il y a peu sur developpez : http://www.developpez.net/forums/d11...e-utilise-jvm/

Tout comme il est possible d'avoir des compilateur C/C++ écrit en C/C++ ;)

a++
21/02/2012, 15h39
Luc Hermitte

Citation:

Envoyé par Nemek

a- Concernant le deuxième point, la portabilité que tu peux t'accorder en C++ s'arrête au source "annoté". Il faut en effet ajouter des instructions de pré-compilations pour avoir un source "multi-plateforme". Et impossible d'avoir un .o ou .so ou .dll portable. Sur les systèmes UNIX avec la gestion des dépendances, ca peut se gérer (et encore !) mais pour Windows t'es marron.
Et franchement reconstruire un produit pour pouvoir l'utiliser c'est tout de même assez "con" comme principe.

b- Tu n'obtiendras pas la même portabilité rien qu'au niveau des sources et absolument aucune au niveau binaire.

c- L'interdiction de l'héritage multiple paraît assez naturelle car elle évite de nombreux problèmes d'utilisation, que cela n'ajoute finalement pas grand chose, ca clarifie le code et que ca simplifie/optimise la compilation et l'exécution. Si on met dans une balance, ca penche beaucoup plus en faveur de l'interdiction que l'autorisation.

d- koala> base OO == substituabilité
On dit "polymorphisme" :zoubi:

e- Où est l'hérésie de dire que dans un langage objet tout est objet ?
Pour autant que je sache, je peux tous les deux les décrire, les toucher et les manipuler.

f- Non ce n'est pas rare et c'est pourquoi il y a les interfaces. Le vrai problème c'est de déterminer le code à exécuter dans le cadre de l'héritage multiple (voir le problème du diamand).

g- Dans le paradigme objet, il n'y a pas de fonction et tout comportement est rattaché à un objet ... Java utilise le paradigme impératif uniquement pour décrire les comportements et ce n'est pas général à l'OO.

h- Une map permet de créer une association non structurelle entre deux objets, donc oui, c'est normal que tout puisse être clé d'une map ... C'est une forme simpifiée d'inversion de contrôle.

i- Pourquoi ne pas le faire si c'est nécessaire ? D'ailleurs tu fais comment un code générique si tu n'acceptes pas un point commun ?
D'ailleurs avec un nom comme boost::any, je vois pas trop la différence avec java.lang.Object ???
void* n'est ni plus, ni moins qu'un java.lang.Object sans comportement. Quand tu vois la part de code Java qui sont basés sur les méthodes de "base", tu te rends bien compte du temps gagné !

k- Super si tu manipules des objets qui viennent de deux framework différents !

l- koala01, je voudrais juste finir en m'excusant si tu le prends mal. Je n'ai rien contre toi mais tes remarques m'ont fait bondir ^^

a- Tu te trompes. Les choses ont bien changé.
Nous avons quantité de bibliothèques qui nous assurent la portabilité du code métier. Et elle est de qualité équivalente à ce qui ce passe en java (aujourd'hui -- il y a eu des progrès depuis le coup de gueule de RSM pour OOo) quand on change de compilo ou même de version de VM & co.
Pour les libs, nous avons aussi des outils magiques comme cmake qui s'occupent de tout pour nous -- même si pas encore parfait, c'est un excellent début.

b- S'il n'y a que ça qui compte, autant coder dans des langages interprétés ...

c- On y perd le NVI avec l'interdiction. C'est cher payer la présomption d'incompétence.

d- La base c'est bien le LSP. -> Principe de Substitution de Liskov
Le choix des mots n'est pas un hasard chez nous. Trop souvent on voit de l'héritage utilisé à tord parce que le LSP n'a pas été compris (cf carrés & rectangles, listes et listes triées, etc). Polymorphisme [Accessoirement, un concept plus général et bien antérieur à l'OO.] est un mot qui est souvent très mal assimilé, il suffit de voir les tentatives d'explication qui trainent à base de "prend plusieurs formes" qui ne veulent strictement rien dire.

e- Aux dernières nouvelles int ou les tableaux ne sont pas des objets en Java. En Ruby j'aurai été d'accord.

f- Pour que ce problème se pose, c'est que le LSP n'a pas été correctement appliqué. [je ne fais que paraphraser Koala]

g- Il y a des limites. Typiquement dans les lib mathématiques. Rattacher les fonctions trigo à des objets n'a pas de sens. D'ailleurs ce n'est pas le cas, c'est juste rattaché à classes qui servent alors d'espaces de noms. Sauf qu'ils ne sont pas extensibles.

h- même un int ?
Désolé, elle était facile.
Plus sérieusement. Koala (arrête moi si je me trompe) critiquait que la clé n'impose pas précisément le type attendu, et que donc on peut avoir une map à clés hétérogènes. Les générics corrigent ça, mais c'est juste un sucre syntaxique et il est toujours nécessaire d'avoir une fonction de comparaison qui doit assumer qu'il peut y avoir eu un cas foireux dans le code et donc tester à l'exécution que les types sont bien comparables -- cf toutes les digressions qui ont suivi.
Là où le typage du C++ nous aurait envoyé ballader dès la compilation.

i- void* et le superobject sont décriés en C++.
Et C++ a pris la voie des concepts -- même si on n'a pas su les mettre en oeuvre proprement -- trop d'historique et pas assez de temps je crains. Je renvoie de nouveau à la video de Stépanov.

k- et ?

l- Tout pareil :p
21/02/2012, 16h02
adiGuba

Citation:

Envoyé par Luc Hermitte

e- Aux dernières nouvelles int ou les tableaux ne sont pas des objets en Java.

Pour info en Java les tableaux sont bien des objets, même s'ils sont un peu spéciaux).

a++
21/02/2012, 16h10
Luc Hermitte

Citation:

Envoyé par adiGuba

Pour info en Java les tableaux sont bien des objets, même s'ils sont un peu spéciaux).

Ah? Au temps pour moi.
J'y rejetterai un œil à l'occasion.
21/02/2012, 17h14
hegros

Citation:

Envoyé par zaventem

Pour ma part, affirmer que deux objets sont égaux signifie qu'ils sont interchangeables, que d'un point de vue logique (après, l'implémentation est un autre aspect qui a ses propres contraintes) je peux utiliser l'un ou l'autre sans que cela ne change quoi que se soit. Ainsi, une méthode paramétrique Equals<T> me parait incongrue, une pomme ne sera jamais égale à une poire. Elles peuvent être semblable, avoir certains aspects identiques mais elles ne seront jamais égale.

Pour continuer sur ton exemple de workflow, il me semble une fois de plus que de leur donner la responsabilité de déterminer s'ils sont égaux entre eux me semble une erreur de conception. Dans le cas trivial où leur identité ne dépendrait que de l'état dans lequel l'université se trouve est réalisable mais l'énoncé même me semble indiquer la raison pour ne pas le faire: leur équivalence est fonction d'un élément qui ne dépend pas d'eux.

Oui mes exemples et énoncés sont loin d'être parfaits et alors ?

Leurs objectifs ne sont que de creuser, mettre en évidence et distinguer la compréhension de ce que l'on nomme test d'égalité et exposer des points de divergence. En même temps votre position est facile vous ne pouvez pas trouver d'exemples ni d'énoncés puisque vous n'y voyez pas d’intérêts :).

De manière général nous sommes tous d'accord sur un ensemble d'éléments et il y a divergence ensuite sur un ensemble d'élément (notamment le test d'équivalence qui fait qu'une poire pourrait être une pomme selon le modèle théorique employé)
21/02/2012, 17h28
Luc Hermitte

Citation:

Envoyé par hegros

Oui mes exemples et énoncés sont loin d'être parfaits et alors ?

Leurs objectifs ne sont que de creuser, mettre en évidence et distinguer la compréhension de ce que l'on nomme test d'égalité et exposer des points de divergence. En même temps votre position est facile vous ne pouvez pas trouver d'exemples ni d'énoncés puisque vous n'y voyez pas d’intérêts :).

Et alors, tu n'en trouveras pas. Cela ne vient pas de toi.

Notre position facile ? Maintenant oui. Au départ nous faisions (moi en tout cas) bien plus de boulot que nécessaire à vouloir supporter égalité et copiabilité sur des entités. Avec le recul j'ai fini par me rendre compte que cela ne m'a jamais servi à rien.
Je me sens un peu un agnostique dans tout ça. Des cas particuliers qui contredisent notre approche de la chose peuvent exister, mais nous les estimons suffisamment rares pour les traiter au cas par cas.
Si nous avions été concepteurs de langages peut-être aurions nous interdis ces choses auxquelles nous ne voyions pas d'intérêt. Qui sait ? :D
21/02/2012, 18h20
Logan Mauzaize

Citation:

Envoyé par adiGuba

Il est tout à fait possible d'avoir une JVM en Java ! C'est d'ailleurs un des objectif d'Oracle pour la JVM officiel (à long terme). On en a parlé il y a peu sur developpez : http://www.developpez.net/forums/d11...e-utilise-jvm/

Tout comme il est possible d'avoir des compilateur C/C++ écrit en C/C++ ;)

a++

Si j'ai bien suivi l'article (qui était dans mon pipe ^^), il s'agit du compilateur (ByteCode -> Code natif) qui est écrit en Java ? Je suppose qu'il s'agit de générer directement le code machine correspondant aux instructions ByteCode ?
Si c'est cela oui effectivement c'est possible mais ca revient à faire générer de l'assembleur et le donner au compilateur du fondeur.
Car en l'absence d'instruction pour représenter des manipulations mémoires et des appels systèmes, il faut les écrire sous forme d'instruction binaire pour chaque plateforme. Alors qu'un compilateur C++ il en existe déjà pour toutes les plateformes envisagées par la JVM.
21/02/2012, 18h50
adiGuba

Ben l'idée c'est de ne plus dépendre d'un compilateur C/C++.

Comme les compilateur C/C++ se sont passé de la dépendance de compilateur de code assembleur...

Je n'ai pas vraiment de connaissance en développement d'un compilateur, mais je ne vois pas en quoi ce serait impossible en Java...

a++
21/02/2012, 19h22
koala01

Citation:

Envoyé par Nemek

L'interdiction de l'héritage multiple paraît assez naturelle car elle évite de nombreux problèmes d'utilisation, que cela n'ajoute finalement pas grand chose, ca clarifie le code et que ca simplifie/optimise la compilation et l'exécution. Si on met dans une balance, ca penche beaucoup plus en faveur de l'interdiction que l'autorisation.

Le fait est que, lorsque tu pars sur le principe d'une super classe de base, tu te retrouveras, fatalement, avec un héritage en diamant!!!

L'héritage multiple n'est pas plus mauvais que l'héritage simple: il faut juste se rappeler que l'héritage multiple doit nous inciter à plus de prudence lorsqu'on l'envisage (mais il faut déjà être particulièrement prudent lorsque l'on envisage l'héritage simple, de manière générale :D )

Citation:

Je dirai plutôt que tout le monde se prenne pour un "crack", que ca permet d'accéder plus facilement à la compétence de "développeur". Pas besoin de penser comme une machine pour coder, c'est tout de même appréciable. Ensuite la philosophie, c'est qu'en se libérant de la résolution de problèmes "bas-niveau" (comme l'allocation, la virtualité, passage par copie/référence), un développeur d'un langage de "haut-niveau", peut se concentrer sur des problèmes plus grands et plus complexes. Et ainsi un gain non négligeable en productivité.

Je ne dis pas qu'il faut penser comme une machine pour programmer, je dis juste qu'il faut connaitre un minimum les principes qui permettent de le faire

Tout comme tu n'oserais sans doute pas laisser coder quelqu'un qui ignore comment choisir entre les différents types de boucles dans n'importe quel langage impératifs, j'estime qu'il ne faut pas s'étonner d'avoir des problèmes lorsqu'on laisse coder les gens avec un langage OO alors qu'il ne comprennent pas (ou pire à moitié) les principes qui régissent le paradigme OO.

Evidemment, il existe, j'en suis convaincu, des gens qui comprennent et maitrisent les principes du paradigme OO et qui codent en java ;)

Je ne dis que cela!!!

Le problème, et je reviendrai là dessus juste un peu plus tard, c'est que java (ou tout langage qui limite volontairement les possibilités du paradigme OO) permet d'obtenir quelque chose "qui marche" en n'ayant qu'une connaissance et une compréhension partielle des principes OO, voire, qui confondent carrément certains principes

C++ est peut etre, à l'inverse, un peu trop permissif, mais c'est sans doute un bien car la première chose que l'on martèle aux gens, c'est, justement, les principes de base (et pas seulement du paradigme OO :D) , et son s'assure qu'il les auront bien compris.

Au final, un type qui passe de C++ à java va sans doute pester énormément sur les restrictions qui lui sont imposées, mais il arrivera "facilement" à obtenir une conception qui "tient la route", simplement parce qu'il pourra (pour ne pas dire qu'il devra) se permettre d'appliquer les principes de base avec un peu plus de souplesse.

A l'inverse, quelqu'un qui passe de java à C++ risque d'avoir énormément de problème parce que, justement, il risque de ne pas avoir la réelle compréhension de ces principes, et donc, de faire des choses qui les violent, bien qu'étant permises par le langage!!!

Mais ce n'est pas le langage qui est mauvais, à ce moment là, c'est le concepteur ;)

Citation:

On dit "polymorphisme" :zoubi:

Justement, non!!!

Le principe de base de l'OO, c'est la substituabilité, au sens du Principe de substitution de Liskov.

Le principe de l'OO, c'est le fait de pouvoir passer un objet dont le type est Derivee là où j'attends un objet dont le type est Base et que cela continue à fonctionner!!!

Le polymorphisme découle directement du respect de LSP, mais c'est le fait que, si un comportement est (correctement :D ) redéfini (et je n'ai pas dit surchargée ;)) dans la classe Derivee, ce sera le comportement du type Derivee qui sera utilisé et non le comportement de la classe de base (pour autant, bien sur, que nous soyons dans une situation dans laquelle la substitution ait été appliquée ;))

Quelque part, ta remarque est la preuve flagrante de ce que j'exprimais quelques lignes plus haut ;)

Sur les cinq piliers du paradigme OO (ségrégation de l'interface, inversion des dépendances, responsabilité unique, open / close et principe de substitution de liskov), java vous incite à devenir champion dans trois de ces aspects (ségrégation de l'interface, open / close et inversion des dépendance), mais vous incite à ignorer totalement les deux derniers: "Responsabilité unique :question: ben quoi, ma voiture, elle doit se tracer ;)" "Liskov :question: c'est qui celle là :question: Qu'est ce qu'elle nous a encore pondu comme anerie :question:" sont, à peu de choses près des remarques que j'ai déjà reçues de la part de javaistes (et de quelques codeurs vraiment débutants en C++ quand meme ;))

Citation:

Où est l'hérésie de dire que dans un langage objet tout est objet ?
Pour autant que je sache, je peux tous les deux les décrire, les toucher et les manipuler.

C'est une hérésie au sens du respect du LSP, dés le départ!!!

Le simple fait que tu puisses décider de passer "tout et n'importe quoi", sans distinction aucune, y compris (j'ai envide de dire "et surtout") des objets dont les types n'ont, a priori, aucun lien et aucune raison d'avoir le moindre lien, ca ne te choque pas :question:

Le fait que tu puisses décider de créer une collection (quelle qu'elle soit ;)) d'objet tout à fait hétéroclites n'ayant aucuns lien entre autre et aucune raison d'en avoir, ca ne te choque pas :question:

Plus haut, on m'as dit "oui, c'est pour cela que l'on déconseille fortement de créer une telle collection" (ce n'est pas une citation, mais l'idée est là, hein? ;) ), mais, si vous vous rendez déjà compte que "c'est pas bien" de le faire, comment pourriez vous justifier le fait que le langage vous l'autorise de facto et vous oblige littéralement à faire en sorte que ce soit possible :question:

Citation:

Non ce n'est pas rare et c'est pourquoi il y a les interfaces. Le vrai problème c'est de déterminer le code à exécuter dans le cadre de l'héritage multiple (voir le problème du diamand).

L'héritage en diamant n'est qu'un "cas particulier" de l'héritage multiple ;)

Évidemment, si on part d'office avec une super classe de base, cela devient le cas général et unique, mais, dans une conception bien faite (allez, je le dis : "dans le monde des bisounours ;) :D ), les différents comportements obtenus par héritage multiples seront, en réalité, totalement transversaux ;)

Citation:

Dans le paradigme objet, il n'y a pas de fonction et tout comportement est rattaché à un objet ... Java utilise le paradigme impératif uniquement pour décrire les comportements et ce n'est pas général à l'OO.

Montre moi un seul bouquin de conception OO qui ne soit pas orienté java ou C# (car ils ont clairement fait le choix de l'obliger :aie:) dans lequel on dit que toute fonction doit d'office faire partie d'un objet, et je pourrai te croire ;)

Attention, je respecte le choix de java de dire que toute fonction doit etre fonction membre, mais ce n'est nullement une obligation en terme OO ;)

Autrement, les langages multiparadigmes ne respecteraient jamais les principe de l'orienté objet ;)

Citation:

Pour te paraphraser :

Celui à qui je faisais allusion a clairement dit qu'il ne voulait pas entendre parler de ce paradigme...

Mais je ne relèverai pas l'attaque plus ou moins personnelle ;)

Citation:

Une map permet de créer une association non structurelle entre deux objets, donc oui, c'est normal que tout puisse être clé d'une map ... C'est une forme simpifiée d'inversion de contrôle.

Que tout puisse être clé de map, à la limite, cela ne me dérange pas...

Mais que dans une même map, il devienne possible d'avoir un ensemble hétérogène de clés, ca, ca m'inquiète quand meme énormément (oui Luc, tu as bien compris ce que je voulais dire ;))

Citation:

Si tu te permet de juger un concept abstrait sur la base d'un exemple d'un monde ultra-limité, alors abandonnes la programmation ou contentes-toi de pisser du code ;)

J'ai donné des exemples simples, et je peux, si tu le souhaites, te donner des exemples bien plus concrets ;)

Maintenant, donne moi un exemple qui tienne la route, qui respecte les principes OO qui me montre que j'ai tort, et je te ferai mes plus plattes excuses ;)

Citation:

Et pour autant que je sache, en C++, je peux comparer tous mes pointeurs ...

En les castant en void* oui, mais ca, c'est l'héritage du C (contre lequel on lutte à longueur de journée ;)

Citation:

Pourquoi ne pas le faire si c'est nécessaire ? D'ailleurs tu fais comment un code générique si tu n'acceptes pas un point commun ?

Que penses tu... du paradigme générique, et des classes (et fonction template) :question:

Citation:

D'ailleurs avec un nom comme boost::any, je vois pas trop la différence avec java.lang.Object ???

La différence :question:

C'est que tu restes libre d'utiliser l'un alors que tu es obligé d'utiliser l'autre, même si cela ne t'intéresse pas ;)

Citation:

void* n'est ni plus, ni moins qu'un java.lang.Object sans comportement. Quand tu vois la part de code Java qui sont basés sur les méthodes de "base", tu te rends bien compte du temps gagné !

C'est étrange, je n'ai jamais utilisé un seul void* dans un code C++... serais-je un extra terrestre :question:

Citation:

Super si tu manipules des objets qui viennent de deux framework différents !

Qui te dis que deux frameworks différents utiliseront fatalement un God Object :question:

Citation:

Je te rassure ce sont biens des aberrations, mais en général on préfére le pragmatisme au conceptuel ...

Où est le pragmatisme quand on n'a pas le choix :question:

Si je dois décider, par pragmatisme, de faire quelque chose, j'aimerais autant avoir la possibilité de faire autrement pour choisir la meilleure manière de faire (ou en tout cas la moins mauvaise ;))

Citation:

koala01, je voudrais juste finir en m'excusant si tu le prends mal. Je n'ai rien contre toi mais tes remarques m'ont fait bondir ^^

ne t'en fais pas, je n'ai pas l'habitude de prendre la mouche ;)
21/02/2012, 20h15
gl

Citation:

Envoyé par Nemek

Citation:

Il est assez frappant de constater que la réponse que la plupart des gens apportent à la question "quelle est la base de la programmation OO" et l'encapsulation, alors que la base de la programmation OO est en réalité... la subsituabilité (comprend : le fait qu'un objet de n'importe quel type héritant d'une classe de base puisse "passer pour" un objet de la classe de base elle-même).

On dit "polymorphisme" :zoubi:

Indépendamment des remarques qui ont déjà été faites sur le choix des mots qui n'est pas innocent (remarques avec lesquelles je suis tout à fait d'accord au passage) : on pourrait éventuellement parler de polymorphisme d'inclusion (ou de sous-typage), pas simplement de polymorphisme qui est une notion beaucoup plus générique (il y a d'autres formes de polymorphismes).

Voir 40 message(s) de cette discussion en une page