Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça ne
l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore",
c'est qque chose qui mange de la viande, indépendamment de la façon dont
ce
qque chose sera implémenté: un tigre, un chien, une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière
uniforme des objets hétérogènes (un tigre, un chien, une drosera) qui ont
un
ensemble de méthodes communes (qui mangent tous de la viande).
Et, de la même manière que la grammaire usuelle nous permet d'appliquer un
nombre quelconque d'adjectifs qualificatifs à un nom (un animal carnivore,
agressif, diurne, etc.), Java permet d'appliquer un nombre quelconque
d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des "spécifications" à
des classes, sans être contraint par un schéma d'héritage rigide. Ca offre
plusieurs avantages par rapport à l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les
noms).
Bruno.
"sifrit" wrote in message
news:Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça ne
l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore",
c'est qque chose qui mange de la viande, indépendamment de la façon dont
ce
qque chose sera implémenté: un tigre, un chien, une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière
uniforme des objets hétérogènes (un tigre, un chien, une drosera) qui ont
un
ensemble de méthodes communes (qui mangent tous de la viande).
Et, de la même manière que la grammaire usuelle nous permet d'appliquer un
nombre quelconque d'adjectifs qualificatifs à un nom (un animal carnivore,
agressif, diurne, etc.), Java permet d'appliquer un nombre quelconque
d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des "spécifications" à
des classes, sans être contraint par un schéma d'héritage rigide. Ca offre
plusieurs avantages par rapport à l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les
noms).
Bruno.
"sifrit" <sifrit@noreply.fr> wrote in message
news:Xns963EDBF485C27sifrit@212.27.42.78...
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça ne
l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore",
c'est qque chose qui mange de la viande, indépendamment de la façon dont
ce
qque chose sera implémenté: un tigre, un chien, une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière
uniforme des objets hétérogènes (un tigre, un chien, une drosera) qui ont
un
ensemble de méthodes communes (qui mangent tous de la viande).
Et, de la même manière que la grammaire usuelle nous permet d'appliquer un
nombre quelconque d'adjectifs qualificatifs à un nom (un animal carnivore,
agressif, diurne, etc.), Java permet d'appliquer un nombre quelconque
d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des "spécifications" à
des classes, sans être contraint par un schéma d'héritage rigide. Ca offre
plusieurs avantages par rapport à l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les
noms).
Bruno.
"sifrit" wrote in message
news:Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le truc
graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette question
qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça
ne l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore", c'est qque chose qui mange de la viande, indépendamment
de la façon dont ce qque chose sera implémenté: un tigre, un chien,
une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière uniforme des objets hétérogènes (un tigre, un chien, une
drosera) qui ont un ensemble de méthodes communes (qui mangent tous de
la viande).
Et, de la même manière que la grammaire usuelle nous permet
d'appliquer un nombre quelconque d'adjectifs qualificatifs à un nom
(un animal carnivore, agressif, diurne, etc.), Java permet d'appliquer
un nombre quelconque d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des
"spécifications" à des classes, sans être contraint par un schéma
d'héritage rigide. Ca offre plusieurs avantages par rapport à
l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais
pas les noms).
Bruno.
"sifrit" wrote in message
news:Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le
truc graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette
question qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça
ne l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore", c'est qque chose qui mange de la viande, indépendamment
de la façon dont ce qque chose sera implémenté: un tigre, un chien,
une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière uniforme des objets hétérogènes (un tigre, un chien, une
drosera) qui ont un ensemble de méthodes communes (qui mangent tous de
la viande).
Et, de la même manière que la grammaire usuelle nous permet
d'appliquer un nombre quelconque d'adjectifs qualificatifs à un nom
(un animal carnivore, agressif, diurne, etc.), Java permet d'appliquer
un nombre quelconque d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des
"spécifications" à des classes, sans être contraint par un schéma
d'héritage rigide. Ca offre plusieurs avantages par rapport à
l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais
pas les noms).
Bruno.
"sifrit" <sifrit@noreply.fr> wrote in message
news:Xns963EDBF485C27sifrit@212.27.42.78...
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le
truc graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette
question qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça
ne l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore", c'est qque chose qui mange de la viande, indépendamment
de la façon dont ce qque chose sera implémenté: un tigre, un chien,
une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière uniforme des objets hétérogènes (un tigre, un chien, une
drosera) qui ont un ensemble de méthodes communes (qui mangent tous de
la viande).
Et, de la même manière que la grammaire usuelle nous permet
d'appliquer un nombre quelconque d'adjectifs qualificatifs à un nom
(un animal carnivore, agressif, diurne, etc.), Java permet d'appliquer
un nombre quelconque d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des
"spécifications" à des classes, sans être contraint par un schéma
d'héritage rigide. Ca offre plusieurs avantages par rapport à
l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais
pas les noms).
Bruno.
"sifrit" wrote in message
news:Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le
truc graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette
question qui me tarode.(exhaustivement et en détail ) svp
Merci!!
plusieurs avantages par rapport à l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les noms).
plusieurs avantages par rapport à l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les noms).
plusieurs avantages par rapport à l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les noms).
"Bruno Jouhier" wrote in
news:426752ca$0$21148$:Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça
ne l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore", c'est qque chose qui mange de la viande, indépendamment
de la façon dont ce qque chose sera implémenté: un tigre, un chien,
une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière uniforme des objets hétérogènes (un tigre, un chien, une
drosera) qui ont un ensemble de méthodes communes (qui mangent tous de
la viande).
Et, de la même manière que la grammaire usuelle nous permet
d'appliquer un nombre quelconque d'adjectifs qualificatifs à un nom
(un animal carnivore, agressif, diurne, etc.), Java permet d'appliquer
un nombre quelconque d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des
"spécifications" à des classes, sans être contraint par un schéma
d'héritage rigide. Ca offre plusieurs avantages par rapport à
l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais
pas les noms).
Bruno.
"sifrit" wrote in message
news:Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le
truc graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette
question qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Merci beaucoup sa me parrait un peu plus clair ^^.
En plus un réponse assez rapide et pertinente
"Bruno Jouhier" <bjouhier@club-internet.fr> wrote in
news:426752ca$0$21148$7a628cd7@news.club-internet.fr:
Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça
ne l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore", c'est qque chose qui mange de la viande, indépendamment
de la façon dont ce qque chose sera implémenté: un tigre, un chien,
une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière uniforme des objets hétérogènes (un tigre, un chien, une
drosera) qui ont un ensemble de méthodes communes (qui mangent tous de
la viande).
Et, de la même manière que la grammaire usuelle nous permet
d'appliquer un nombre quelconque d'adjectifs qualificatifs à un nom
(un animal carnivore, agressif, diurne, etc.), Java permet d'appliquer
un nombre quelconque d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des
"spécifications" à des classes, sans être contraint par un schéma
d'héritage rigide. Ca offre plusieurs avantages par rapport à
l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais
pas les noms).
Bruno.
"sifrit" <sifrit@noreply.fr> wrote in message
news:Xns963EDBF485C27sifrit@212.27.42.78...
Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le
truc graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette
question qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Merci beaucoup sa me parrait un peu plus clair ^^.
En plus un réponse assez rapide et pertinente
"Bruno Jouhier" wrote in
news:426752ca$0$21148$:Un peu de grammaire:
* Les classes, ce sont les substantifs (les noms) de ton programme
* Les méthodes, ce sont les verbes.
* Les interfaces, ce sont les adjectifs qualificatifs.
Ca a peut-être l'air un peu farfelu comme présentation mais en fait ça
ne l'est pas tant que ça:
* Un nom, c'est une "implementation" particulière: un "chien", ça a 4
pattes, des crocs, etc.
* Un adjectif qualificatif, c'est une "spécification pure": un
"carnivore", c'est qque chose qui mange de la viande, indépendamment
de la façon dont ce qque chose sera implémenté: un tigre, un chien,
une drosera.
L'intérêt des interfaces, c'est qu'elles permettent de manipuler de
manière uniforme des objets hétérogènes (un tigre, un chien, une
drosera) qui ont un ensemble de méthodes communes (qui mangent tous de
la viande).
Et, de la même manière que la grammaire usuelle nous permet
d'appliquer un nombre quelconque d'adjectifs qualificatifs à un nom
(un animal carnivore, agressif, diurne, etc.), Java permet d'appliquer
un nombre quelconque d'interfaces à une classe donnée.
Les interfaces, c'est donc ce qui pemet d'attribuer des
"spécifications" à des classes, sans être contraint par un schéma
d'héritage rigide. Ca offre plusieurs avantages par rapport à
l'héritage multiple:
* C'est plus souple.
* Ca évite des problèmes complexes comme l'héritage "répété".
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais
pas les noms).
Bruno.
"sifrit" wrote in message
news:Bonsoir,
En cours actuellement on a abordé le principe d'interface ( pas le
truc graphique).
Mais je n'en comprend pas l'interet.
Es ce que quelqu'un aurait un lien ou pourrait repondre a cette
question qui me tarode.(exhaustivement et en détail ) svp
Merci!!
Merci beaucoup sa me parrait un peu plus clair ^^.
En plus un réponse assez rapide et pertinente
le Thursday 21 April 2005 09:14, écrivit :plusieurs avantages par rapport à l'héritage multiple:
hmm, là ça dévie de la question je trouve, puisqu'en java il n'y a pas
d'héritage multiple, c'est un argumentaire pro-java innoportun..
Dans d'autres langages (C++ ..) L'héritage multiple est utilisable
(conjointement avec des fonctions abstraites) pour jouer le rôle que
interface joue en java.* C'est plus souple.
c'est un peu osé ça. la différence entre une interface java, et une classe
C++ abstraite, c'est justement que l'interface java est plus rigide - ce
qu'on peut voir comme un avantage (ou pas).
On peut faire une classe abstraite, et si on y mets *que* des méthodes
virtuelles pures elle jouera exactement le rôle d'une interface java.
Mais contrairement à l'interface, on peut aussi y définir des méthodes.
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne sera
pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les noms).
mouais bon, je ne suis pas convaincu que cette analogie aie un quelconque
interêt. Pour me prêter au jeu, je rétorquerais que la "grammaire
naturelle", comme la plupart de ce que fait l'homme, n'est pas rigide.
Il arrive qu'on combine plusieurs noms, qu'on fasse un verbe d'un
adjectif, ..
--
Samuel
le Thursday 21 April 2005 09:14, bjouhier@club-internet.fr écrivit :
plusieurs avantages par rapport à l'héritage multiple:
hmm, là ça dévie de la question je trouve, puisqu'en java il n'y a pas
d'héritage multiple, c'est un argumentaire pro-java innoportun..
Dans d'autres langages (C++ ..) L'héritage multiple est utilisable
(conjointement avec des fonctions abstraites) pour jouer le rôle que
interface joue en java.
* C'est plus souple.
c'est un peu osé ça. la différence entre une interface java, et une classe
C++ abstraite, c'est justement que l'interface java est plus rigide - ce
qu'on peut voir comme un avantage (ou pas).
On peut faire une classe abstraite, et si on y mets *que* des méthodes
virtuelles pures elle jouera exactement le rôle d'une interface java.
Mais contrairement à l'interface, on peut aussi y définir des méthodes.
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne sera
pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les noms).
mouais bon, je ne suis pas convaincu que cette analogie aie un quelconque
interêt. Pour me prêter au jeu, je rétorquerais que la "grammaire
naturelle", comme la plupart de ce que fait l'homme, n'est pas rigide.
Il arrive qu'on combine plusieurs noms, qu'on fasse un verbe d'un
adjectif, ..
--
Samuel
le Thursday 21 April 2005 09:14, écrivit :plusieurs avantages par rapport à l'héritage multiple:
hmm, là ça dévie de la question je trouve, puisqu'en java il n'y a pas
d'héritage multiple, c'est un argumentaire pro-java innoportun..
Dans d'autres langages (C++ ..) L'héritage multiple est utilisable
(conjointement avec des fonctions abstraites) pour jouer le rôle que
interface joue en java.* C'est plus souple.
c'est un peu osé ça. la différence entre une interface java, et une classe
C++ abstraite, c'est justement que l'interface java est plus rigide - ce
qu'on peut voir comme un avantage (ou pas).
On peut faire une classe abstraite, et si on y mets *que* des méthodes
virtuelles pures elle jouera exactement le rôle d'une interface java.
Mais contrairement à l'interface, on peut aussi y définir des méthodes.
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne sera
pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
* Ca correspond mieux à notre "grammaire naturelle" (dans laquelle les
adjectifs peuvent être combinés à volonté dans une définition, mais pas
les noms).
mouais bon, je ne suis pas convaincu que cette analogie aie un quelconque
interêt. Pour me prêter au jeu, je rétorquerais que la "grammaire
naturelle", comme la plupart de ce que fait l'homme, n'est pas rigide.
Il arrive qu'on combine plusieurs noms, qu'on fasse un verbe d'un
adjectif, ..
--
Samuel
Et alors. On n'a pas le droit d'émettre des opinions. Il faut juste
répondre à la question et se tenir au garde-à-vous!
Et ce n'est pas pro-Java, c'est une théorie un peu personnelle que j'avais
déjà développée (mais publiée seulement dans un cercle restreint) en 93,
avant l'arrivée de Java (j'avais appelé ça des types
"adjectifs" à l'époque). Le fait que ça corresponde (presque) aux
interfaces Java a
été une confirmation a posteriori que ça n'était sans doute pas si idiot
que ça.
A mon avis, le bon concept c'est la "classe sans champs", c'est à dire une
classe dans laquelle on a des méthodes abstraites + des méthodes concrètes
(implémentées au-dessus des méthodes abstraites).
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne
sera pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
Si, c'est un vrai problème, avec différentes "bidouilles" pour s'en sortir
(les "virtual base class" de C++, le renommage d'Eiffel, etc.).
Et je n'ai pas écrit qu' "on ne combine pas plusieurs noms" car c'est bien
évidemment faux (par ex: le chat, le chien et le canard sont dans la
cour),
Il est assez rare qu'on définisse un nom
comme "un xxx est un yyy et un zzz". Et donc, naturellement, notre
grammaire nous conduit à faire de l'héritage simple d'implémentation (de
nom) et de l'héritage multiple de spécification (d'adjectifs
qualificatifs).
ce long processus. Mais je pense qu'on aurait tort de croire qu'il n'y a
que
des rapports "accidentels" entre nos langages artificiels et nos
grammaires naturelles. Le lien est beaucoup plus profond.
Et alors. On n'a pas le droit d'émettre des opinions. Il faut juste
répondre à la question et se tenir au garde-à-vous!
Et ce n'est pas pro-Java, c'est une théorie un peu personnelle que j'avais
déjà développée (mais publiée seulement dans un cercle restreint) en 93,
avant l'arrivée de Java (j'avais appelé ça des types
"adjectifs" à l'époque). Le fait que ça corresponde (presque) aux
interfaces Java a
été une confirmation a posteriori que ça n'était sans doute pas si idiot
que ça.
A mon avis, le bon concept c'est la "classe sans champs", c'est à dire une
classe dans laquelle on a des méthodes abstraites + des méthodes concrètes
(implémentées au-dessus des méthodes abstraites).
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne
sera pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
Si, c'est un vrai problème, avec différentes "bidouilles" pour s'en sortir
(les "virtual base class" de C++, le renommage d'Eiffel, etc.).
Et je n'ai pas écrit qu' "on ne combine pas plusieurs noms" car c'est bien
évidemment faux (par ex: le chat, le chien et le canard sont dans la
cour),
Il est assez rare qu'on définisse un nom
comme "un xxx est un yyy et un zzz". Et donc, naturellement, notre
grammaire nous conduit à faire de l'héritage simple d'implémentation (de
nom) et de l'héritage multiple de spécification (d'adjectifs
qualificatifs).
ce long processus. Mais je pense qu'on aurait tort de croire qu'il n'y a
que
des rapports "accidentels" entre nos langages artificiels et nos
grammaires naturelles. Le lien est beaucoup plus profond.
Et alors. On n'a pas le droit d'émettre des opinions. Il faut juste
répondre à la question et se tenir au garde-à-vous!
Et ce n'est pas pro-Java, c'est une théorie un peu personnelle que j'avais
déjà développée (mais publiée seulement dans un cercle restreint) en 93,
avant l'arrivée de Java (j'avais appelé ça des types
"adjectifs" à l'époque). Le fait que ça corresponde (presque) aux
interfaces Java a
été une confirmation a posteriori que ça n'était sans doute pas si idiot
que ça.
A mon avis, le bon concept c'est la "classe sans champs", c'est à dire une
classe dans laquelle on a des méthodes abstraites + des méthodes concrètes
(implémentées au-dessus des méthodes abstraites).
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne
sera pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
Si, c'est un vrai problème, avec différentes "bidouilles" pour s'en sortir
(les "virtual base class" de C++, le renommage d'Eiffel, etc.).
Et je n'ai pas écrit qu' "on ne combine pas plusieurs noms" car c'est bien
évidemment faux (par ex: le chat, le chien et le canard sont dans la
cour),
Il est assez rare qu'on définisse un nom
comme "un xxx est un yyy et un zzz". Et donc, naturellement, notre
grammaire nous conduit à faire de l'héritage simple d'implémentation (de
nom) et de l'héritage multiple de spécification (d'adjectifs
qualificatifs).
ce long processus. Mais je pense qu'on aurait tort de croire qu'il n'y a
que
des rapports "accidentels" entre nos langages artificiels et nos
grammaires naturelles. Le lien est beaucoup plus profond.
le Friday 22 April 2005 21:48, écrivit :Et alors. On n'a pas le droit d'émettre des opinions. Il faut juste
répondre à la question et se tenir au garde-à-vous!
non, je te l'accorde :)
j'avais eu l'impression d'une prêche anti-C++ à la seule évocation du mot
interface, je vois que ça n'y ressemblait qu'en surface.Et ce n'est pas pro-Java, c'est une théorie un peu personnelle que
j'avais
déjà développée (mais publiée seulement dans un cercle restreint) en 93,
avant l'arrivée de Java (j'avais appelé ça des types
"adjectifs" à l'époque). Le fait que ça corresponde (presque) aux
interfaces Java a
été une confirmation a posteriori que ça n'était sans doute pas si idiot
que ça.
La réflexion que tu présentes à la fin de ton message sur les similarités
fondamentales entre langage de communication et de programmation est
intéressante.
Je suis assez d'accord, mais la similarité a aussi des limites, les
langages
de programmation (pour l'instant en tout cas) sont particuliers : leur but
est la description de comportement, de liens entre des objets.
les interfaces sont des "adjectifs" qui disent toujours :
peut faire-ci avec tel truc, peut faire ça ..
On pourrait dire que les adjectifs aussi, si l'on introduit suffisament de
choses ("vert" -> peut émettre de la lumière.. "beau" ? déja plus dur)
Pour moi la différence fondamentale est que le langage humain est ambigu
par
_essence_, même si on peut essayer de décrire un adjectif par ses
relations
avec les autres concepts.
Tandis qu'un langage de programmation au contraire ne sort jamais du cadre
de la définition de relations précises. Au fur et à mesure qu'on accumule
des entités, les concepts en jeu peuvent devenir un peu plus abstraits,
presque vague, mais tout part de définitions précises. C'est un peu le
sens
inverse de ce qui se passe avec le langage humain.
enfin bon, ça devient métaphysique de discuter langages..
donc :
ok, langage humain et programmation ont des similarités, mais aussi des
différences fondamentales.
A mon avis, le bon concept c'est la "classe sans champs", c'est à dire
une
classe dans laquelle on a des méthodes abstraites + des méthodes
concrètes
(implémentées au-dessus des méthodes abstraites).
oui c'est vrai que c'est un bon schéma. ça peut se faire en C++, et pas en
java, et je connais un programmeur C++ qui cite ça souvent contre java.
L'héritage multiple laisse énormément de liberté, ça a du bon meme si ça
permet aussi de se mettre dans des situations compliquées et faire des
erreurs dures à cerner..* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne
sera pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
Si, c'est un vrai problème, avec différentes "bidouilles" pour s'en
sortir
(les "virtual base class" de C++, le renommage d'Eiffel, etc.).
ce que je voulais dire, c'est que de l'héritage répété, ça marche, ce
n'est
pas une erreur à moins que ce ne soit pas ce qu'on veuille..
Il peut y avoir des cas où l'héritage répété est le comportement voulu
(même
si c'est pas très fréquent en pratique, on peut avoir à réaliser des
modèles de classes utiles qui portent 2 casquettes, similaires mais
indépendantes)Et je n'ai pas écrit qu' "on ne combine pas plusieurs noms" car c'est
bien
évidemment faux (par ex: le chat, le chien et le canard sont dans la
cour),
je pensais à des combinaisons comme "président-directeur général",
poisson-chat, chasseur-ceuilleur, pollueur-payeur ..
bref, les noms sont parfois combinés comme le seraient des adjectifs, et
dans la comparasion ça correspondrait assez exactement au gentil chaos
possible grâce à l'héritage multiple (qui permet toute sorte de
croisements
entre classes abstraites et classe normale)
Il est assez rare qu'on définisse un nom
comme "un xxx est un yyy et un zzz". Et donc, naturellement, notre
grammaire nous conduit à faire de l'héritage simple d'implémentation (de
nom) et de l'héritage multiple de spécification (d'adjectifs
qualificatifs).
rare, mais ça arrive.
[..]ce long processus. Mais je pense qu'on aurait tort de croire qu'il n'y a
que
des rapports "accidentels" entre nos langages artificiels et nos
grammaires naturelles. Le lien est beaucoup plus profond.
c'est vrai que ça parait même logique quand on y réfléchit, c'est
intéressant.
(mais ça ne m'enlève pas de l'idée que l'héritage multiple a sa place ! :)
--
Samuel
le Friday 22 April 2005 21:48, bjouhier@club-internet.fr écrivit :
Et alors. On n'a pas le droit d'émettre des opinions. Il faut juste
répondre à la question et se tenir au garde-à-vous!
non, je te l'accorde :)
j'avais eu l'impression d'une prêche anti-C++ à la seule évocation du mot
interface, je vois que ça n'y ressemblait qu'en surface.
Et ce n'est pas pro-Java, c'est une théorie un peu personnelle que
j'avais
déjà développée (mais publiée seulement dans un cercle restreint) en 93,
avant l'arrivée de Java (j'avais appelé ça des types
"adjectifs" à l'époque). Le fait que ça corresponde (presque) aux
interfaces Java a
été une confirmation a posteriori que ça n'était sans doute pas si idiot
que ça.
La réflexion que tu présentes à la fin de ton message sur les similarités
fondamentales entre langage de communication et de programmation est
intéressante.
Je suis assez d'accord, mais la similarité a aussi des limites, les
langages
de programmation (pour l'instant en tout cas) sont particuliers : leur but
est la description de comportement, de liens entre des objets.
les interfaces sont des "adjectifs" qui disent toujours :
peut faire-ci avec tel truc, peut faire ça ..
On pourrait dire que les adjectifs aussi, si l'on introduit suffisament de
choses ("vert" -> peut émettre de la lumière.. "beau" ? déja plus dur)
Pour moi la différence fondamentale est que le langage humain est ambigu
par
_essence_, même si on peut essayer de décrire un adjectif par ses
relations
avec les autres concepts.
Tandis qu'un langage de programmation au contraire ne sort jamais du cadre
de la définition de relations précises. Au fur et à mesure qu'on accumule
des entités, les concepts en jeu peuvent devenir un peu plus abstraits,
presque vague, mais tout part de définitions précises. C'est un peu le
sens
inverse de ce qui se passe avec le langage humain.
enfin bon, ça devient métaphysique de discuter langages..
donc :
ok, langage humain et programmation ont des similarités, mais aussi des
différences fondamentales.
A mon avis, le bon concept c'est la "classe sans champs", c'est à dire
une
classe dans laquelle on a des méthodes abstraites + des méthodes
concrètes
(implémentées au-dessus des méthodes abstraites).
oui c'est vrai que c'est un bon schéma. ça peut se faire en C++, et pas en
java, et je connais un programmeur C++ qui cite ça souvent contre java.
L'héritage multiple laisse énormément de liberté, ça a du bon meme si ça
permet aussi de se mettre dans des situations compliquées et faire des
erreurs dures à cerner..
* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne
sera pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
Si, c'est un vrai problème, avec différentes "bidouilles" pour s'en
sortir
(les "virtual base class" de C++, le renommage d'Eiffel, etc.).
ce que je voulais dire, c'est que de l'héritage répété, ça marche, ce
n'est
pas une erreur à moins que ce ne soit pas ce qu'on veuille..
Il peut y avoir des cas où l'héritage répété est le comportement voulu
(même
si c'est pas très fréquent en pratique, on peut avoir à réaliser des
modèles de classes utiles qui portent 2 casquettes, similaires mais
indépendantes)
Et je n'ai pas écrit qu' "on ne combine pas plusieurs noms" car c'est
bien
évidemment faux (par ex: le chat, le chien et le canard sont dans la
cour),
je pensais à des combinaisons comme "président-directeur général",
poisson-chat, chasseur-ceuilleur, pollueur-payeur ..
bref, les noms sont parfois combinés comme le seraient des adjectifs, et
dans la comparasion ça correspondrait assez exactement au gentil chaos
possible grâce à l'héritage multiple (qui permet toute sorte de
croisements
entre classes abstraites et classe normale)
Il est assez rare qu'on définisse un nom
comme "un xxx est un yyy et un zzz". Et donc, naturellement, notre
grammaire nous conduit à faire de l'héritage simple d'implémentation (de
nom) et de l'héritage multiple de spécification (d'adjectifs
qualificatifs).
rare, mais ça arrive.
[..]
ce long processus. Mais je pense qu'on aurait tort de croire qu'il n'y a
que
des rapports "accidentels" entre nos langages artificiels et nos
grammaires naturelles. Le lien est beaucoup plus profond.
c'est vrai que ça parait même logique quand on y réfléchit, c'est
intéressant.
(mais ça ne m'enlève pas de l'idée que l'héritage multiple a sa place ! :)
--
Samuel
le Friday 22 April 2005 21:48, écrivit :Et alors. On n'a pas le droit d'émettre des opinions. Il faut juste
répondre à la question et se tenir au garde-à-vous!
non, je te l'accorde :)
j'avais eu l'impression d'une prêche anti-C++ à la seule évocation du mot
interface, je vois que ça n'y ressemblait qu'en surface.Et ce n'est pas pro-Java, c'est une théorie un peu personnelle que
j'avais
déjà développée (mais publiée seulement dans un cercle restreint) en 93,
avant l'arrivée de Java (j'avais appelé ça des types
"adjectifs" à l'époque). Le fait que ça corresponde (presque) aux
interfaces Java a
été une confirmation a posteriori que ça n'était sans doute pas si idiot
que ça.
La réflexion que tu présentes à la fin de ton message sur les similarités
fondamentales entre langage de communication et de programmation est
intéressante.
Je suis assez d'accord, mais la similarité a aussi des limites, les
langages
de programmation (pour l'instant en tout cas) sont particuliers : leur but
est la description de comportement, de liens entre des objets.
les interfaces sont des "adjectifs" qui disent toujours :
peut faire-ci avec tel truc, peut faire ça ..
On pourrait dire que les adjectifs aussi, si l'on introduit suffisament de
choses ("vert" -> peut émettre de la lumière.. "beau" ? déja plus dur)
Pour moi la différence fondamentale est que le langage humain est ambigu
par
_essence_, même si on peut essayer de décrire un adjectif par ses
relations
avec les autres concepts.
Tandis qu'un langage de programmation au contraire ne sort jamais du cadre
de la définition de relations précises. Au fur et à mesure qu'on accumule
des entités, les concepts en jeu peuvent devenir un peu plus abstraits,
presque vague, mais tout part de définitions précises. C'est un peu le
sens
inverse de ce qui se passe avec le langage humain.
enfin bon, ça devient métaphysique de discuter langages..
donc :
ok, langage humain et programmation ont des similarités, mais aussi des
différences fondamentales.
A mon avis, le bon concept c'est la "classe sans champs", c'est à dire
une
classe dans laquelle on a des méthodes abstraites + des méthodes
concrètes
(implémentées au-dessus des méthodes abstraites).
oui c'est vrai que c'est un bon schéma. ça peut se faire en C++, et pas en
java, et je connais un programmeur C++ qui cite ça souvent contre java.
L'héritage multiple laisse énormément de liberté, ça a du bon meme si ça
permet aussi de se mettre dans des situations compliquées et faire des
erreurs dures à cerner..* Ca évite des problèmes complexes comme l'héritage "répété".
disons qu'avec le systeme d'interface, plus rigide, le programmeur ne
sera pas exposé à des problèmes qui peuvent se poser avec de l'héritage
multiple.
L'héritage "répété" n'est pas en soi un problème.. c'est juste un eceuil
supplémentaire sur lequel des programmeurs peuvent se tromper.
Si, c'est un vrai problème, avec différentes "bidouilles" pour s'en
sortir
(les "virtual base class" de C++, le renommage d'Eiffel, etc.).
ce que je voulais dire, c'est que de l'héritage répété, ça marche, ce
n'est
pas une erreur à moins que ce ne soit pas ce qu'on veuille..
Il peut y avoir des cas où l'héritage répété est le comportement voulu
(même
si c'est pas très fréquent en pratique, on peut avoir à réaliser des
modèles de classes utiles qui portent 2 casquettes, similaires mais
indépendantes)Et je n'ai pas écrit qu' "on ne combine pas plusieurs noms" car c'est
bien
évidemment faux (par ex: le chat, le chien et le canard sont dans la
cour),
je pensais à des combinaisons comme "président-directeur général",
poisson-chat, chasseur-ceuilleur, pollueur-payeur ..
bref, les noms sont parfois combinés comme le seraient des adjectifs, et
dans la comparasion ça correspondrait assez exactement au gentil chaos
possible grâce à l'héritage multiple (qui permet toute sorte de
croisements
entre classes abstraites et classe normale)
Il est assez rare qu'on définisse un nom
comme "un xxx est un yyy et un zzz". Et donc, naturellement, notre
grammaire nous conduit à faire de l'héritage simple d'implémentation (de
nom) et de l'héritage multiple de spécification (d'adjectifs
qualificatifs).
rare, mais ça arrive.
[..]ce long processus. Mais je pense qu'on aurait tort de croire qu'il n'y a
que
des rapports "accidentels" entre nos langages artificiels et nos
grammaires naturelles. Le lien est beaucoup plus profond.
c'est vrai que ça parait même logique quand on y réfléchit, c'est
intéressant.
(mais ça ne m'enlève pas de l'idée que l'héritage multiple a sa place ! :)
--
Samuel
