Le code suivant est valide (sauf faute de frappe ;)):
class A
{
protected:
virtual void f() = 0;
};
void A::f()
{
cout << "A::f" << endl;
}
class B : public A
{
virtual void f();
void g();
}
void B::f()
{
cout << "B::f" << endl;
}
Le code suivant est valide (sauf faute de frappe ;)):
class A
{
protected:
virtual void f() = 0;
};
void A::f()
{
cout << "A::f" << endl;
}
class B : public A
{
virtual void f();
void g();
}
void B::f()
{
cout << "B::f" << endl;
}
Le code suivant est valide (sauf faute de frappe ;)):
class A
{
protected:
virtual void f() = 0;
};
void A::f()
{
cout << "A::f" << endl;
}
class B : public A
{
virtual void f();
void g();
}
void B::f()
{
cout << "B::f" << endl;
}
(Vincent) wrote in message news:...
Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes
abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...
Non, l'héritant voit aussi les classes ca1 et ca2, et il voit qu'il
doit hériter de l'une et aggréger l'autre en republiant son interface
à l'extérieur. C'est ça qui est anormal.
ça n'est nullement une obligation, en fait ça n'est nécessaire que
vclassine@elan.fr (Vincent) wrote in message news:<9e49e584.0307312244.688fad2a@posting.google.com>...
Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes
abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...
Non, l'héritant voit aussi les classes ca1 et ca2, et il voit qu'il
doit hériter de l'une et aggréger l'autre en republiant son interface
à l'extérieur. C'est ça qui est anormal.
ça n'est nullement une obligation, en fait ça n'est nécessaire que
(Vincent) wrote in message news:...
Ta solution marche effectivement, mais elle pose un gros problème : tu fais
confiance à l'utilisateur de ta bibliothèque pour implémenter (en tou cas en
partie) la fonctionnalité de pré/postconditions.
L'appel aux pre/postcondition n'est visible que dans les classes
abstraites CA1 et CA2... L'"héritant" ou l'utilisateur n'en ont pas
connaissance. L'héritant vois en plus de i1 et i2 les fonctions
do_fX() mais je ne vois pas comment il pourrait les redéfinir sans
ça...
Non, l'héritant voit aussi les classes ca1 et ca2, et il voit qu'il
doit hériter de l'une et aggréger l'autre en republiant son interface
à l'extérieur. C'est ça qui est anormal.
ça n'est nullement une obligation, en fait ça n'est nécessaire que
"Loïc Joly" a écrit dans le message de
news:bgd4pg$v5d$Le code suivant est valide (sauf faute de frappe ;)):
class A
{
protected:
virtual void f() = 0;
};
void A::f()
{
cout << "A::f" << endl;
}
class B : public A
{
virtual void f();
void g();
}
void B::f()
{
cout << "B::f" << endl;
}
J'ai appris celà il y a quelque temps déjà, dans un vieux thread sur
les destructeurs virtuels. Pour Vincent : le =0 n'empeche pas de
définir la fonction dans la classe mère, mais oblige à la (re-)définir
dans les classes filles.
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de
news:bgd4pg$v5d$1@news-reader2.wanadoo.fr...
Le code suivant est valide (sauf faute de frappe ;)):
class A
{
protected:
virtual void f() = 0;
};
void A::f()
{
cout << "A::f" << endl;
}
class B : public A
{
virtual void f();
void g();
}
void B::f()
{
cout << "B::f" << endl;
}
J'ai appris celà il y a quelque temps déjà, dans un vieux thread sur
les destructeurs virtuels. Pour Vincent : le =0 n'empeche pas de
définir la fonction dans la classe mère, mais oblige à la (re-)définir
dans les classes filles.
"Loïc Joly" a écrit dans le message de
news:bgd4pg$v5d$Le code suivant est valide (sauf faute de frappe ;)):
class A
{
protected:
virtual void f() = 0;
};
void A::f()
{
cout << "A::f" << endl;
}
class B : public A
{
virtual void f();
void g();
}
void B::f()
{
cout << "B::f" << endl;
}
J'ai appris celà il y a quelque temps déjà, dans un vieux thread sur
les destructeurs virtuels. Pour Vincent : le =0 n'empeche pas de
définir la fonction dans la classe mère, mais oblige à la (re-)définir
dans les classes filles.
Loïc Joly wrote in message
news:<bgakd0$g0g$...Vincent wrote:"Christophe Lephay" wrote in
message news:<bg6dhs$ihj$...C'est juste un paradigme supplémentaire (programmation générique,
inspiré de la programmation fonctionnelle). Dans le même ordre
d'idée, on pourrait dire que le paradigme OO n'est pas
indispensable quoique utile.
Je ne sais pas si on peut aller jusque là, il faut que je sois
ammener à faire du C++ ou que j'attende la version 1.5 de java
pour en mesurer toute la puissance.
Je ne sais pas si la version Java des templates sera aussi puissante
que la version C++ (langage turing-complet, principe de certaines
utilisations des templates de faire des choses à la compilation
difficilement applicable dans un envronneement JIT...).
A moins que tu aies plus de détails sur cette version, je pense
qu'il y a un risque que les templates Java ne soient rien d'autre
qu'un mécanisme pour avoir des conteneurs type-safe. Ce qui est déjà
très bien en soit, et justifierait largement AMA l'introduction des
templates en Java, mais qui ne permettrai pas d'en faire tout ce
qu'on peut en faire en C++.
Non pas d'infos, j'espère qu'il vont le faire au mieux... après les
limites du JIT...
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bgakd0$g0g$1@news-reader4.wanadoo.fr>...
Vincent wrote:
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in
message news:<bg6dhs$ihj$1@news-reader3.wanadoo.fr>...
C'est juste un paradigme supplémentaire (programmation générique,
inspiré de la programmation fonctionnelle). Dans le même ordre
d'idée, on pourrait dire que le paradigme OO n'est pas
indispensable quoique utile.
Je ne sais pas si on peut aller jusque là, il faut que je sois
ammener à faire du C++ ou que j'attende la version 1.5 de java
pour en mesurer toute la puissance.
Je ne sais pas si la version Java des templates sera aussi puissante
que la version C++ (langage turing-complet, principe de certaines
utilisations des templates de faire des choses à la compilation
difficilement applicable dans un envronneement JIT...).
A moins que tu aies plus de détails sur cette version, je pense
qu'il y a un risque que les templates Java ne soient rien d'autre
qu'un mécanisme pour avoir des conteneurs type-safe. Ce qui est déjà
très bien en soit, et justifierait largement AMA l'introduction des
templates en Java, mais qui ne permettrai pas d'en faire tout ce
qu'on peut en faire en C++.
Non pas d'infos, j'espère qu'il vont le faire au mieux... après les
limites du JIT...
Loïc Joly wrote in message
news:<bgakd0$g0g$...Vincent wrote:"Christophe Lephay" wrote in
message news:<bg6dhs$ihj$...C'est juste un paradigme supplémentaire (programmation générique,
inspiré de la programmation fonctionnelle). Dans le même ordre
d'idée, on pourrait dire que le paradigme OO n'est pas
indispensable quoique utile.
Je ne sais pas si on peut aller jusque là, il faut que je sois
ammener à faire du C++ ou que j'attende la version 1.5 de java
pour en mesurer toute la puissance.
Je ne sais pas si la version Java des templates sera aussi puissante
que la version C++ (langage turing-complet, principe de certaines
utilisations des templates de faire des choses à la compilation
difficilement applicable dans un envronneement JIT...).
A moins que tu aies plus de détails sur cette version, je pense
qu'il y a un risque que les templates Java ne soient rien d'autre
qu'un mécanisme pour avoir des conteneurs type-safe. Ce qui est déjà
très bien en soit, et justifierait largement AMA l'introduction des
templates en Java, mais qui ne permettrai pas d'en faire tout ce
qu'on peut en faire en C++.
Non pas d'infos, j'espère qu'il vont le faire au mieux... après les
limites du JIT...
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | David, c'est l'expertise sans égale de toutes les
| > | détails des templates
| > Non, là tu es en train de parler John Spicer :-)
| C'est vrai. Encore que la différence n'est pas énorme.
Ça dépend à quelle echelle tu te places. Vu de Chulak, tu as
probablement raison.
| (Et encore, je ne suis pas sûr. Je parie que David a plus
| d'expérience à l'utilisation des templates.)
| > Demande à David si tu ne me crois pas.
| Ce qui ne prouverait rien.
et dans ce cas qu'est-ce qui prouverait quelque chose ? Le fait que tu
assertes qu'il est l'Expert ?
| Je crois que tu sais aussi bien que moi que David est une personne
| extrèmement modeste, toujours prêt à donner plus de crédit aux
| autres, et moins à lui-même, qu'il ne se doit.
David est très modeste. Certes. Mais au de là sa modestie, il dit
aussi la vérité. Demande lui plus de détails sur la part de John dans
l'elaboration du bouquin.
Encore une fois : je ne veux en aucun diminuer le mérite de David.
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3oezc9vpd.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.fr writes:
| > | David, c'est l'expertise sans égale de toutes les
| > | détails des templates
| > Non, là tu es en train de parler John Spicer :-)
| C'est vrai. Encore que la différence n'est pas énorme.
Ça dépend à quelle echelle tu te places. Vu de Chulak, tu as
probablement raison.
| (Et encore, je ne suis pas sûr. Je parie que David a plus
| d'expérience à l'utilisation des templates.)
| > Demande à David si tu ne me crois pas.
| Ce qui ne prouverait rien.
et dans ce cas qu'est-ce qui prouverait quelque chose ? Le fait que tu
assertes qu'il est l'Expert ?
| Je crois que tu sais aussi bien que moi que David est une personne
| extrèmement modeste, toujours prêt à donner plus de crédit aux
| autres, et moins à lui-même, qu'il ne se doit.
David est très modeste. Certes. Mais au de là sa modestie, il dit
aussi la vérité. Demande lui plus de détails sur la part de John dans
l'elaboration du bouquin.
Encore une fois : je ne veux en aucun diminuer le mérite de David.
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | David, c'est l'expertise sans égale de toutes les
| > | détails des templates
| > Non, là tu es en train de parler John Spicer :-)
| C'est vrai. Encore que la différence n'est pas énorme.
Ça dépend à quelle echelle tu te places. Vu de Chulak, tu as
probablement raison.
| (Et encore, je ne suis pas sûr. Je parie que David a plus
| d'expérience à l'utilisation des templates.)
| > Demande à David si tu ne me crois pas.
| Ce qui ne prouverait rien.
et dans ce cas qu'est-ce qui prouverait quelque chose ? Le fait que tu
assertes qu'il est l'Expert ?
| Je crois que tu sais aussi bien que moi que David est une personne
| extrèmement modeste, toujours prêt à donner plus de crédit aux
| autres, et moins à lui-même, qu'il ne se doit.
David est très modeste. Certes. Mais au de là sa modestie, il dit
aussi la vérité. Demande lui plus de détails sur la part de John dans
l'elaboration du bouquin.
Encore une fois : je ne veux en aucun diminuer le mérite de David.
Vincent wrote:Je rappel pour ceux qui veulent répondre à la question qu'elle à été
posé par un débutant...
oui mais dans ce cas, la réponse n'est ni java ni c++, mais plutôt ADA,
au moins, il prendra de bonnes habitudes :).
Vincent wrote:
Je rappel pour ceux qui veulent répondre à la question qu'elle à été
posé par un débutant...
oui mais dans ce cas, la réponse n'est ni java ni c++, mais plutôt ADA,
au moins, il prendra de bonnes habitudes :).
Vincent wrote:Je rappel pour ceux qui veulent répondre à la question qu'elle à été
posé par un débutant...
oui mais dans ce cas, la réponse n'est ni java ni c++, mais plutôt ADA,
au moins, il prendra de bonnes habitudes :).
(Vincent) wrote in message
news:...wrote in message
news:...(Vincent) wrote in message
news:...wrote in message
news:...(Vincent) wrote in message
news:...(Endymion) wrote in message
news:...Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques
petites particularités syntaxiques (syntaxe de création d'un
tableau, l'utilisation de destructeur d'objet,
l'initialisation par défaut des champs) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques
sont la conséquence de différences de fond.Est-ce que l'héritage multiple change vraiment quelque chose ?
D'abord en java tu peux faire de l'héritage multiple
d'interfaces (une interface peut hériter de plusieurs autres,
et une classe peut implémenter plus d'interfaces).
Une interface logique définit un contrat. Avec des invariants,
des préconditions et des postconditions. Qu'on ne peut pas
vérifier dans une interface Java.Ce que tu ne peut pas faire c'est de l'héritage multiple de
comportement (une classe hérite de plusieurs).
A partir de là le fait que l'héritage multiple de classe soit
interdit rend pénible l'écriture de certains code, mais a
aussi des avantages de sécurité (d'ailleurs on pourrait dire
qu'il en va de même pour l'héritage simple de comportement).
Quel est l'avantage de sécurité ? Où plutôt, où sont les risques
associées à l'héritage multiple.
Les mêmes que ceux de l'héritage simple, mais multipliés.
C-à-d.Risque de fonctionnement incorrect si on ne documente pas la
manière d'hériter.
On n'a pas besoin de l'héritage pour ça.
??? pas besoins de l'hritage pour "mal hériter d'une classe"????
On n'a pas besoin de l'héritage pour qu'une classe ne remplit pas son
contrat.
Il ne s'agit pas vraiment de contrat (ou alors du contrat avec
Risque d'impossibilité partielle de changer l'implémentation si on
documente en vue d'un héritage...
Explique. Je ne comprends pas ce que tu essaies de dire.
Par exemple si tu redéfinis equals de Object en java, il est fortement
conseillé de redéfinir hashcode, pour des raisons de compatibilité
avec certaines Collections (HashTreeMap...). ça c'est pour la
nécessité de documenter... Dans ce cas précis on révèle partiellement
l'implémentation des collections. Il est possible que suite à un
changement d'implémentation de HashTreeMap il devienne aussi
nécessaire de redéfinir une autre méthode d'object.
Si ça n'est pas fait on perd la compatibilité... Ce qui constitue un
risque pour l'évolutivité. En gros, avec l'héritage, une partie de
l'implémentation peu devenir immuable, car elle fait en fait partie du
contrat avec les classes filles...
Si j'ai bien compris, ce que tu dis revient à dire que la classe de base
définit un contrat, et que ce contrat limite l'évolutivité. Je l'espère
bien. Le but du contrat, c'est précisement à spécifier ce qui peut
changer, et ce qui ne peut pas.
Sauf qu'il s'agit d'un "contrat d'héritage" pas d'un "contrat public",
Le problème, évidemment, peut se présenter quand le contrat est mal
spécifié ; quand on exige des choses qui ne sont pas nécessaire.
C'est ça, mais ça n'est pas forcément un mauvais choix, ça peut être
Je suis
d'accord que quelque chose comme exiger à toute classe de supporter une
fonction du genre « toString » est indicatif d'une erreur de conception.
En l'occurence il y en a une implémentation par défaut dans Object, si
Mais l'héritage multiple n'y est pour rien.
ça c'est sûr, simplement ça induit la notion de conflit...
Bon ça c'est côté classe mère. Côté fille, l'héritage multiple
restreint encore un peu la marge de manoeuvre. En effet si on
considère le cas d'un changement d'impémentation nécessaire dans une
classe mère impliquant des modifs d'implémentation dans les classes
filles. Ces modifs risques d'entrer en conflit avec les contraintes
d'implémentation d'une autre classe mère dont hériterait aussi la
classe fille...
Là, il faudrait que tu me donnes un exemple. Réel.
Un exemple (fictif) deux classe qui hérite de classes mères ayant
Une classe joue un
rôle dans l'application. Le contrat, ou les contrats, qu'elle implémente
dépend de cette rôle. Or, il est évident que si ce contrat comporte des
contradictions, on a un problème.
Je parle de contradictions pour la rédéfinitions de méthodes de même
Mais justement, l'héritage multiple
aide à limiter des problèmes -- si une classe fille hérite de deux
classes mères, il y a deux contrats, dont d'autres classes peuvent n'en
implémenter qu'un seul. S'il n'y a qu'une seule classe de base, en
revanche, il faut que toutes les classes qui veulent implémenter une
partie du contrat en implémente le tout.
Tu oublies l'héritage multiple d'interface.
Tu me diras que c'est des cas rares, certes. Mais les cas où
l'héritage multiple est nécessaire sont rares, et la gymnastique
d'implémentation via les interfaces et la composition n'est pas
insurontables...
L'implémentation n'est pas insurmontable, mais le résultat est bien plus
difficile à comprendre et à faire évoluer.
Pas vraiment, si c'est fait dans les règles de l'art. Par contre ça
Personnelement je ne serais pas contre l'introduction de la
fonctionalité dans java, mais je comprends que ça comporte des risques
d'abus. Risques peut-être plus important que les bénéfices. Mais là
c'est philosophique: "incitation à la sécurité" ou "pleine puissance
d'expression", le compromis est difficile et subjectif...
Le problème, c'est que ce n'est pas l'héritage multiple qui introduit
les risques.
Conflits de contrats d'héritage, spécifique à l'héritage multiple...
Le problème, c'est des contrats mal-défini. Et c'est une
risque que l'héritage multiple permet à limiter.
Ceci dit, je suis sceptique en ce qui concerne les possibilités du
langage à limiter des risques d'erreur de conception. Il intervient bien
trop tard.
Certes, mais ce que je dis c'est pas vraiment du domaine de la
[...]Si tu as besoin d'une vrai portabilité, il faut C++.
C'est vrai qu'il y a portabilité et portabilité... Dans un cas java
est bon dans l'autre inutilisable...
Alors, on est d'accord. Au moins sur la principe. Java et C++ ont deux
approches radicalement différentes en ce qui concerne la portabilité ;
on pourrait dire qu'ils ont même deux définitions différentes de la
portabilité. J'ai travaillé beaucoup dans des domaines où l'approche C++
était la seule valable. Je travaille actuellement dans des domaines où
les deux se valent, à peu de chose près (mais s'il y a un avantage,
c'est de côté C++). Mais je comprends bien qu'il y a des cas où
l'approche Java est intéressant -- c'est le cas des logiciels clients,
par exemple. (Dans ce cas-ci, la question de portabilité est liée, au
moins en partie, à la question de deployement.)
Effectivement, mais au delà des possibilités de portabilité, il y a
Mais dans l'ensemble, je m'attendrais à un
peu plus de lignes en C++. Parce que tu fais plus -- tu vérifies les
précondtions et les postconditions (que tu ne peux pas faire en
java), par exemple. Le resultat, c'est un code plus robuste en C++.
pour info:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
si ce dont tu parles ne se trouve pas dans cette page tu peux me
donner un exemple en C++, stp.
D'autres l'ont déjà fait -- c'est qu'on ne peut pas redéfinir la
fonction pour empêcher l'execution des vérifications.
Je ne vois pas, on ne peut pas redéfinir une fonction "final", où est
le problème?
Que les fonctions d'un interface ne peut pas être « final ».
Je ne l'aurais pas dit comme ça mais bon...
Et qu'on ne
peut pas hériter de plusieurs classes abstraites.
Si, sur le plan des pre/post conditions, mais de manière différentes.
vclassine@elan.fr (Vincent) wrote in message
news:<9e49e584.0307310137.d3dc8d4@posting.google.com>...
kanze@gabi-soft.fr wrote in message
news:<d6652001.0307300242.5e461c89@posting.google.com>...
vclassine@elan.fr (Vincent) wrote in message
news:<9e49e584.0307290626.1e09d027@posting.google.com>...
kanze@gabi-soft.fr wrote in message
news:<d6652001.0307290232.155b5e42@posting.google.com>...
vclassine@elan.fr (Vincent) wrote in message
news:<9e49e584.0307280504.515584ab@posting.google.com>...
pr.nm@laposte.net (Endymion) wrote in message
news:<4219ae8a.0307242127.6e18880c@posting.google.com>...
Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques
petites particularités syntaxiques (syntaxe de création d'un
tableau, l'utilisation de destructeur d'objet,
l'initialisation par défaut des champs) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques
sont la conséquence de différences de fond.
Est-ce que l'héritage multiple change vraiment quelque chose ?
D'abord en java tu peux faire de l'héritage multiple
d'interfaces (une interface peut hériter de plusieurs autres,
et une classe peut implémenter plus d'interfaces).
Une interface logique définit un contrat. Avec des invariants,
des préconditions et des postconditions. Qu'on ne peut pas
vérifier dans une interface Java.
Ce que tu ne peut pas faire c'est de l'héritage multiple de
comportement (une classe hérite de plusieurs).
A partir de là le fait que l'héritage multiple de classe soit
interdit rend pénible l'écriture de certains code, mais a
aussi des avantages de sécurité (d'ailleurs on pourrait dire
qu'il en va de même pour l'héritage simple de comportement).
Quel est l'avantage de sécurité ? Où plutôt, où sont les risques
associées à l'héritage multiple.
Les mêmes que ceux de l'héritage simple, mais multipliés.
C-à-d.
Risque de fonctionnement incorrect si on ne documente pas la
manière d'hériter.
On n'a pas besoin de l'héritage pour ça.
??? pas besoins de l'hritage pour "mal hériter d'une classe"????
On n'a pas besoin de l'héritage pour qu'une classe ne remplit pas son
contrat.
Il ne s'agit pas vraiment de contrat (ou alors du contrat avec
Risque d'impossibilité partielle de changer l'implémentation si on
documente en vue d'un héritage...
Explique. Je ne comprends pas ce que tu essaies de dire.
Par exemple si tu redéfinis equals de Object en java, il est fortement
conseillé de redéfinir hashcode, pour des raisons de compatibilité
avec certaines Collections (HashTreeMap...). ça c'est pour la
nécessité de documenter... Dans ce cas précis on révèle partiellement
l'implémentation des collections. Il est possible que suite à un
changement d'implémentation de HashTreeMap il devienne aussi
nécessaire de redéfinir une autre méthode d'object.
Si ça n'est pas fait on perd la compatibilité... Ce qui constitue un
risque pour l'évolutivité. En gros, avec l'héritage, une partie de
l'implémentation peu devenir immuable, car elle fait en fait partie du
contrat avec les classes filles...
Si j'ai bien compris, ce que tu dis revient à dire que la classe de base
définit un contrat, et que ce contrat limite l'évolutivité. Je l'espère
bien. Le but du contrat, c'est précisement à spécifier ce qui peut
changer, et ce qui ne peut pas.
Sauf qu'il s'agit d'un "contrat d'héritage" pas d'un "contrat public",
Le problème, évidemment, peut se présenter quand le contrat est mal
spécifié ; quand on exige des choses qui ne sont pas nécessaire.
C'est ça, mais ça n'est pas forcément un mauvais choix, ça peut être
Je suis
d'accord que quelque chose comme exiger à toute classe de supporter une
fonction du genre « toString » est indicatif d'une erreur de conception.
En l'occurence il y en a une implémentation par défaut dans Object, si
Mais l'héritage multiple n'y est pour rien.
ça c'est sûr, simplement ça induit la notion de conflit...
Bon ça c'est côté classe mère. Côté fille, l'héritage multiple
restreint encore un peu la marge de manoeuvre. En effet si on
considère le cas d'un changement d'impémentation nécessaire dans une
classe mère impliquant des modifs d'implémentation dans les classes
filles. Ces modifs risques d'entrer en conflit avec les contraintes
d'implémentation d'une autre classe mère dont hériterait aussi la
classe fille...
Là, il faudrait que tu me donnes un exemple. Réel.
Un exemple (fictif) deux classe qui hérite de classes mères ayant
Une classe joue un
rôle dans l'application. Le contrat, ou les contrats, qu'elle implémente
dépend de cette rôle. Or, il est évident que si ce contrat comporte des
contradictions, on a un problème.
Je parle de contradictions pour la rédéfinitions de méthodes de même
Mais justement, l'héritage multiple
aide à limiter des problèmes -- si une classe fille hérite de deux
classes mères, il y a deux contrats, dont d'autres classes peuvent n'en
implémenter qu'un seul. S'il n'y a qu'une seule classe de base, en
revanche, il faut que toutes les classes qui veulent implémenter une
partie du contrat en implémente le tout.
Tu oublies l'héritage multiple d'interface.
Tu me diras que c'est des cas rares, certes. Mais les cas où
l'héritage multiple est nécessaire sont rares, et la gymnastique
d'implémentation via les interfaces et la composition n'est pas
insurontables...
L'implémentation n'est pas insurmontable, mais le résultat est bien plus
difficile à comprendre et à faire évoluer.
Pas vraiment, si c'est fait dans les règles de l'art. Par contre ça
Personnelement je ne serais pas contre l'introduction de la
fonctionalité dans java, mais je comprends que ça comporte des risques
d'abus. Risques peut-être plus important que les bénéfices. Mais là
c'est philosophique: "incitation à la sécurité" ou "pleine puissance
d'expression", le compromis est difficile et subjectif...
Le problème, c'est que ce n'est pas l'héritage multiple qui introduit
les risques.
Conflits de contrats d'héritage, spécifique à l'héritage multiple...
Le problème, c'est des contrats mal-défini. Et c'est une
risque que l'héritage multiple permet à limiter.
Ceci dit, je suis sceptique en ce qui concerne les possibilités du
langage à limiter des risques d'erreur de conception. Il intervient bien
trop tard.
Certes, mais ce que je dis c'est pas vraiment du domaine de la
[...]
Si tu as besoin d'une vrai portabilité, il faut C++.
C'est vrai qu'il y a portabilité et portabilité... Dans un cas java
est bon dans l'autre inutilisable...
Alors, on est d'accord. Au moins sur la principe. Java et C++ ont deux
approches radicalement différentes en ce qui concerne la portabilité ;
on pourrait dire qu'ils ont même deux définitions différentes de la
portabilité. J'ai travaillé beaucoup dans des domaines où l'approche C++
était la seule valable. Je travaille actuellement dans des domaines où
les deux se valent, à peu de chose près (mais s'il y a un avantage,
c'est de côté C++). Mais je comprends bien qu'il y a des cas où
l'approche Java est intéressant -- c'est le cas des logiciels clients,
par exemple. (Dans ce cas-ci, la question de portabilité est liée, au
moins en partie, à la question de deployement.)
Effectivement, mais au delà des possibilités de portabilité, il y a
Mais dans l'ensemble, je m'attendrais à un
peu plus de lignes en C++. Parce que tu fais plus -- tu vérifies les
précondtions et les postconditions (que tu ne peux pas faire en
java), par exemple. Le resultat, c'est un code plus robuste en C++.
pour info:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
si ce dont tu parles ne se trouve pas dans cette page tu peux me
donner un exemple en C++, stp.
D'autres l'ont déjà fait -- c'est qu'on ne peut pas redéfinir la
fonction pour empêcher l'execution des vérifications.
Je ne vois pas, on ne peut pas redéfinir une fonction "final", où est
le problème?
Que les fonctions d'un interface ne peut pas être « final ».
Je ne l'aurais pas dit comme ça mais bon...
Et qu'on ne
peut pas hériter de plusieurs classes abstraites.
Si, sur le plan des pre/post conditions, mais de manière différentes.
(Vincent) wrote in message
news:...wrote in message
news:...(Vincent) wrote in message
news:...wrote in message
news:...(Vincent) wrote in message
news:...(Endymion) wrote in message
news:...Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques
petites particularités syntaxiques (syntaxe de création d'un
tableau, l'utilisation de destructeur d'objet,
l'initialisation par défaut des champs) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques
sont la conséquence de différences de fond.Est-ce que l'héritage multiple change vraiment quelque chose ?
D'abord en java tu peux faire de l'héritage multiple
d'interfaces (une interface peut hériter de plusieurs autres,
et une classe peut implémenter plus d'interfaces).
Une interface logique définit un contrat. Avec des invariants,
des préconditions et des postconditions. Qu'on ne peut pas
vérifier dans une interface Java.Ce que tu ne peut pas faire c'est de l'héritage multiple de
comportement (une classe hérite de plusieurs).
A partir de là le fait que l'héritage multiple de classe soit
interdit rend pénible l'écriture de certains code, mais a
aussi des avantages de sécurité (d'ailleurs on pourrait dire
qu'il en va de même pour l'héritage simple de comportement).
Quel est l'avantage de sécurité ? Où plutôt, où sont les risques
associées à l'héritage multiple.
Les mêmes que ceux de l'héritage simple, mais multipliés.
C-à-d.Risque de fonctionnement incorrect si on ne documente pas la
manière d'hériter.
On n'a pas besoin de l'héritage pour ça.
??? pas besoins de l'hritage pour "mal hériter d'une classe"????
On n'a pas besoin de l'héritage pour qu'une classe ne remplit pas son
contrat.
Il ne s'agit pas vraiment de contrat (ou alors du contrat avec
Risque d'impossibilité partielle de changer l'implémentation si on
documente en vue d'un héritage...
Explique. Je ne comprends pas ce que tu essaies de dire.
Par exemple si tu redéfinis equals de Object en java, il est fortement
conseillé de redéfinir hashcode, pour des raisons de compatibilité
avec certaines Collections (HashTreeMap...). ça c'est pour la
nécessité de documenter... Dans ce cas précis on révèle partiellement
l'implémentation des collections. Il est possible que suite à un
changement d'implémentation de HashTreeMap il devienne aussi
nécessaire de redéfinir une autre méthode d'object.
Si ça n'est pas fait on perd la compatibilité... Ce qui constitue un
risque pour l'évolutivité. En gros, avec l'héritage, une partie de
l'implémentation peu devenir immuable, car elle fait en fait partie du
contrat avec les classes filles...
Si j'ai bien compris, ce que tu dis revient à dire que la classe de base
définit un contrat, et que ce contrat limite l'évolutivité. Je l'espère
bien. Le but du contrat, c'est précisement à spécifier ce qui peut
changer, et ce qui ne peut pas.
Sauf qu'il s'agit d'un "contrat d'héritage" pas d'un "contrat public",
Le problème, évidemment, peut se présenter quand le contrat est mal
spécifié ; quand on exige des choses qui ne sont pas nécessaire.
C'est ça, mais ça n'est pas forcément un mauvais choix, ça peut être
Je suis
d'accord que quelque chose comme exiger à toute classe de supporter une
fonction du genre « toString » est indicatif d'une erreur de conception.
En l'occurence il y en a une implémentation par défaut dans Object, si
Mais l'héritage multiple n'y est pour rien.
ça c'est sûr, simplement ça induit la notion de conflit...
Bon ça c'est côté classe mère. Côté fille, l'héritage multiple
restreint encore un peu la marge de manoeuvre. En effet si on
considère le cas d'un changement d'impémentation nécessaire dans une
classe mère impliquant des modifs d'implémentation dans les classes
filles. Ces modifs risques d'entrer en conflit avec les contraintes
d'implémentation d'une autre classe mère dont hériterait aussi la
classe fille...
Là, il faudrait que tu me donnes un exemple. Réel.
Un exemple (fictif) deux classe qui hérite de classes mères ayant
Une classe joue un
rôle dans l'application. Le contrat, ou les contrats, qu'elle implémente
dépend de cette rôle. Or, il est évident que si ce contrat comporte des
contradictions, on a un problème.
Je parle de contradictions pour la rédéfinitions de méthodes de même
Mais justement, l'héritage multiple
aide à limiter des problèmes -- si une classe fille hérite de deux
classes mères, il y a deux contrats, dont d'autres classes peuvent n'en
implémenter qu'un seul. S'il n'y a qu'une seule classe de base, en
revanche, il faut que toutes les classes qui veulent implémenter une
partie du contrat en implémente le tout.
Tu oublies l'héritage multiple d'interface.
Tu me diras que c'est des cas rares, certes. Mais les cas où
l'héritage multiple est nécessaire sont rares, et la gymnastique
d'implémentation via les interfaces et la composition n'est pas
insurontables...
L'implémentation n'est pas insurmontable, mais le résultat est bien plus
difficile à comprendre et à faire évoluer.
Pas vraiment, si c'est fait dans les règles de l'art. Par contre ça
Personnelement je ne serais pas contre l'introduction de la
fonctionalité dans java, mais je comprends que ça comporte des risques
d'abus. Risques peut-être plus important que les bénéfices. Mais là
c'est philosophique: "incitation à la sécurité" ou "pleine puissance
d'expression", le compromis est difficile et subjectif...
Le problème, c'est que ce n'est pas l'héritage multiple qui introduit
les risques.
Conflits de contrats d'héritage, spécifique à l'héritage multiple...
Le problème, c'est des contrats mal-défini. Et c'est une
risque que l'héritage multiple permet à limiter.
Ceci dit, je suis sceptique en ce qui concerne les possibilités du
langage à limiter des risques d'erreur de conception. Il intervient bien
trop tard.
Certes, mais ce que je dis c'est pas vraiment du domaine de la
[...]Si tu as besoin d'une vrai portabilité, il faut C++.
C'est vrai qu'il y a portabilité et portabilité... Dans un cas java
est bon dans l'autre inutilisable...
Alors, on est d'accord. Au moins sur la principe. Java et C++ ont deux
approches radicalement différentes en ce qui concerne la portabilité ;
on pourrait dire qu'ils ont même deux définitions différentes de la
portabilité. J'ai travaillé beaucoup dans des domaines où l'approche C++
était la seule valable. Je travaille actuellement dans des domaines où
les deux se valent, à peu de chose près (mais s'il y a un avantage,
c'est de côté C++). Mais je comprends bien qu'il y a des cas où
l'approche Java est intéressant -- c'est le cas des logiciels clients,
par exemple. (Dans ce cas-ci, la question de portabilité est liée, au
moins en partie, à la question de deployement.)
Effectivement, mais au delà des possibilités de portabilité, il y a
Mais dans l'ensemble, je m'attendrais à un
peu plus de lignes en C++. Parce que tu fais plus -- tu vérifies les
précondtions et les postconditions (que tu ne peux pas faire en
java), par exemple. Le resultat, c'est un code plus robuste en C++.
pour info:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
si ce dont tu parles ne se trouve pas dans cette page tu peux me
donner un exemple en C++, stp.
D'autres l'ont déjà fait -- c'est qu'on ne peut pas redéfinir la
fonction pour empêcher l'execution des vérifications.
Je ne vois pas, on ne peut pas redéfinir une fonction "final", où est
le problème?
Que les fonctions d'un interface ne peut pas être « final ».
Je ne l'aurais pas dit comme ça mais bon...
Et qu'on ne
peut pas hériter de plusieurs classes abstraites.
Si, sur le plan des pre/post conditions, mais de manière différentes.
