bonjour,
je n'arrive pas encore a assimuler le concept de ceci :
List maList = new ArrayList();
au lieu de :
ArrayList maList = new ArrayList();
(valable pour n'importe qu'elle autre interface / classe ...)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gaetan Zoritchak
Manu wrote:
bonjour, je n'arrive pas encore a assimuler le concept de ceci : List maList = new ArrayList(); au lieu de : ArrayList maList = new ArrayList(); (valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
thx
manu
C'est un principe de programmation. On utilise des interfaces qui indiquent le besoin que l'on a (travailler avec une liste d'objet) indépendamment de l'implémentation choisie(ArrayList non synchronisée, ...). Cela permet notamment de modifier facilement son code.
Manu wrote:
bonjour,
je n'arrive pas encore a assimuler le concept de ceci :
List maList = new ArrayList();
au lieu de :
ArrayList maList = new ArrayList();
(valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
thx
manu
C'est un principe de programmation. On utilise des interfaces qui
indiquent le besoin que l'on a (travailler avec une liste d'objet)
indépendamment de l'implémentation choisie(ArrayList non synchronisée,
...). Cela permet notamment de modifier facilement son code.
bonjour, je n'arrive pas encore a assimuler le concept de ceci : List maList = new ArrayList(); au lieu de : ArrayList maList = new ArrayList(); (valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
thx
manu
C'est un principe de programmation. On utilise des interfaces qui indiquent le besoin que l'on a (travailler avec une liste d'objet) indépendamment de l'implémentation choisie(ArrayList non synchronisée, ...). Cela permet notamment de modifier facilement son code.
Manu
Manu wrote:
bonjour, je n'arrive pas encore a assimuler le concept de ceci : List maList = new ArrayList(); au lieu de : ArrayList maList = new ArrayList(); (valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
thx
manu
C'est un principe de programmation. On utilise des interfaces qui indiquent le besoin que l'on a (travailler avec une liste d'objet) indépendamment de l'implémentation choisie(ArrayList non synchronisée, ...). Cela permet notamment de modifier facilement son code. ok soit, mais alors... le besoin que l'on a est de travailler avec une
liste... mais on ne peut pas car on veut les fonctionnalitees d'une de ses implementations ?! donc je ne comprend toujours pas la logique :( car si on marque List maList = new ArrayList(); on ne veux pas travailler avec une "List" mais avec un "ArrayList"... sauf si ce que je dois comprendre est que : ma variable "maList" etant en "List" me permet donc de communiquer plus facilement avec une autre variable qui elle est reellement "List = new List" ou alors je me pose trop de question .... et devrais juste accepter ce principe de notation...
manu
Manu wrote:
bonjour,
je n'arrive pas encore a assimuler le concept de ceci :
List maList = new ArrayList();
au lieu de :
ArrayList maList = new ArrayList();
(valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
thx
manu
C'est un principe de programmation. On utilise des interfaces qui
indiquent le besoin que l'on a (travailler avec une liste d'objet)
indépendamment de l'implémentation choisie(ArrayList non synchronisée,
...). Cela permet notamment de modifier facilement son code.
ok soit, mais alors... le besoin que l'on a est de travailler avec une
liste... mais on ne peut pas car on veut les fonctionnalitees d'une de
ses implementations ?!
donc je ne comprend toujours pas la logique :( car si on marque
List maList = new ArrayList();
on ne veux pas travailler avec une "List" mais avec un "ArrayList"...
sauf si ce que je dois comprendre est que : ma variable "maList" etant
en "List" me permet donc de communiquer plus facilement avec une autre
variable qui elle est reellement "List = new List"
ou alors je me pose trop de question .... et devrais juste accepter ce
principe de notation...
bonjour, je n'arrive pas encore a assimuler le concept de ceci : List maList = new ArrayList(); au lieu de : ArrayList maList = new ArrayList(); (valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
thx
manu
C'est un principe de programmation. On utilise des interfaces qui indiquent le besoin que l'on a (travailler avec une liste d'objet) indépendamment de l'implémentation choisie(ArrayList non synchronisée, ...). Cela permet notamment de modifier facilement son code. ok soit, mais alors... le besoin que l'on a est de travailler avec une
liste... mais on ne peut pas car on veut les fonctionnalitees d'une de ses implementations ?! donc je ne comprend toujours pas la logique :( car si on marque List maList = new ArrayList(); on ne veux pas travailler avec une "List" mais avec un "ArrayList"... sauf si ce que je dois comprendre est que : ma variable "maList" etant en "List" me permet donc de communiquer plus facilement avec une autre variable qui elle est reellement "List = new List" ou alors je me pose trop de question .... et devrais juste accepter ce principe de notation...
manu
Kupee
Manu wrote:
ok soit, mais alors... le besoin que l'on a est de travailler avec une liste... mais on ne peut pas car on veut les fonctionnalitees d'une de ses implementations ?! donc je ne comprend toujours pas la logique :( car si on marque List maList = new ArrayList(); on ne veux pas travailler avec une "List" mais avec un "ArrayList"... sauf si ce que je dois comprendre est que : ma variable "maList" etant en "List" me permet donc de communiquer plus facilement avec une autre variable qui elle est reellement "List = new List" ou alors je me pose trop de question .... et devrais juste accepter ce principe de notation...
En principe tu n'as pas besoin d'une ArrayList mais d'une List. Ca te permet si tu veux plus tard de la remplacer par un Vector, une LinkedList et bien d'autres choses encore et ton code marchera exactement pareil. et ton objet maList, peu importe que ce soit une ArrayList ou non derriere du moment qu'il stocke et permet de récupérer les données comme tu veux non ?
Manu wrote:
ok soit, mais alors... le besoin que l'on a est de travailler avec une
liste... mais on ne peut pas car on veut les fonctionnalitees d'une de
ses implementations ?!
donc je ne comprend toujours pas la logique :( car si on marque
List maList = new ArrayList();
on ne veux pas travailler avec une "List" mais avec un "ArrayList"...
sauf si ce que je dois comprendre est que : ma variable "maList" etant
en "List" me permet donc de communiquer plus facilement avec une autre
variable qui elle est reellement "List = new List"
ou alors je me pose trop de question .... et devrais juste accepter ce
principe de notation...
En principe tu n'as pas besoin d'une ArrayList mais d'une List.
Ca te permet si tu veux plus tard de la remplacer par un Vector, une
LinkedList et bien d'autres choses encore et ton code marchera
exactement pareil.
et ton objet maList, peu importe que ce soit une ArrayList ou non
derriere du moment qu'il stocke et permet de récupérer les données comme
tu veux non ?
ok soit, mais alors... le besoin que l'on a est de travailler avec une liste... mais on ne peut pas car on veut les fonctionnalitees d'une de ses implementations ?! donc je ne comprend toujours pas la logique :( car si on marque List maList = new ArrayList(); on ne veux pas travailler avec une "List" mais avec un "ArrayList"... sauf si ce que je dois comprendre est que : ma variable "maList" etant en "List" me permet donc de communiquer plus facilement avec une autre variable qui elle est reellement "List = new List" ou alors je me pose trop de question .... et devrais juste accepter ce principe de notation...
En principe tu n'as pas besoin d'une ArrayList mais d'une List. Ca te permet si tu veux plus tard de la remplacer par un Vector, une LinkedList et bien d'autres choses encore et ton code marchera exactement pareil. et ton objet maList, peu importe que ce soit une ArrayList ou non derriere du moment qu'il stocke et permet de récupérer les données comme tu veux non ?
Laurent Bossavit
Manu,
List maList = new ArrayList();
C'est la même différence qu'il existe entre un poste et une personne.
Imagine que tu es un chef de projet, et que tu veux embaucher, disons, un testeur. Pour ce poste, tu vas définir des responsabilités précises; un testeur doit savoir trouver des failles, remplir un rapport de bug, collaborer avec les développeurs au moment de la résolution, etc. Lors de l'embauche, il est rédhibitoire que la personne ne dispose pas de ces compétences.
Par contre, il t'indiffère de savoir si ton candidat est un homme ou une femme, s'il a appris à tester par correspondance ou à l'école, si sa première langue est l'anglais, le français ou le tchèque, et tout un tas de choses qui ne sont pas pertinentes quant à sa capacité à effectuer le travail.
Cependant, il faut bien qu'à un moment donné tu embauches un testeur *précis*; que tu choisisses entre Bob, 6 ans d'expérience dans le jeu vidéo, autodidacte, et Marla, 4 ans d'expérience dans la banque, titulaire d'une maîtrise en info. C'est l'un, ou c'est l'autre - tu ne peux pas embaucher "un testeur" dans l'abstrait.
Laurent http://bossavit.com/thoughts/
Manu,
List maList = new ArrayList();
C'est la même différence qu'il existe entre un poste et une personne.
Imagine que tu es un chef de projet, et que tu veux embaucher, disons,
un testeur. Pour ce poste, tu vas définir des responsabilités précises;
un testeur doit savoir trouver des failles, remplir un rapport de bug,
collaborer avec les développeurs au moment de la résolution, etc. Lors
de l'embauche, il est rédhibitoire que la personne ne dispose pas de ces
compétences.
Par contre, il t'indiffère de savoir si ton candidat est un homme ou une
femme, s'il a appris à tester par correspondance ou à l'école, si sa
première langue est l'anglais, le français ou le tchèque, et tout un tas
de choses qui ne sont pas pertinentes quant à sa capacité à effectuer le
travail.
Cependant, il faut bien qu'à un moment donné tu embauches un testeur
*précis*; que tu choisisses entre Bob, 6 ans d'expérience dans le jeu
vidéo, autodidacte, et Marla, 4 ans d'expérience dans la banque,
titulaire d'une maîtrise en info. C'est l'un, ou c'est l'autre - tu ne
peux pas embaucher "un testeur" dans l'abstrait.
C'est la même différence qu'il existe entre un poste et une personne.
Imagine que tu es un chef de projet, et que tu veux embaucher, disons, un testeur. Pour ce poste, tu vas définir des responsabilités précises; un testeur doit savoir trouver des failles, remplir un rapport de bug, collaborer avec les développeurs au moment de la résolution, etc. Lors de l'embauche, il est rédhibitoire que la personne ne dispose pas de ces compétences.
Par contre, il t'indiffère de savoir si ton candidat est un homme ou une femme, s'il a appris à tester par correspondance ou à l'école, si sa première langue est l'anglais, le français ou le tchèque, et tout un tas de choses qui ne sont pas pertinentes quant à sa capacité à effectuer le travail.
Cependant, il faut bien qu'à un moment donné tu embauches un testeur *précis*; que tu choisisses entre Bob, 6 ans d'expérience dans le jeu vidéo, autodidacte, et Marla, 4 ans d'expérience dans la banque, titulaire d'une maîtrise en info. C'est l'un, ou c'est l'autre - tu ne peux pas embaucher "un testeur" dans l'abstrait.
Laurent http://bossavit.com/thoughts/
Patrick Gras
"Laurent Bossavit" wrote in message news:
Manu,
List maList = new ArrayList();
C'est la même différence qu'il existe entre un poste et une personne.
Imagine que tu es un chef de projet, et que tu veux embaucher, disons, un testeur. Pour ce poste, tu vas définir des responsabilités précises; un testeur doit savoir trouver des failles, remplir un rapport de bug, collaborer avec les développeurs au moment de la résolution, etc. Lors de l'embauche, il est rédhibitoire que la personne ne dispose pas de ces compétences.
Par contre, il t'indiffère de savoir si ton candidat est un homme ou une femme, s'il a appris à tester par correspondance ou à l'école, si sa première langue est l'anglais, le français ou le tchèque, et tout un tas de choses qui ne sont pas pertinentes quant à sa capacité à effectuer le travail.
Cependant, il faut bien qu'à un moment donné tu embauches un testeur *précis*; que tu choisisses entre Bob, 6 ans d'expérience dans le jeu vidéo, autodidacte, et Marla, 4 ans d'expérience dans la banque, titulaire d'une maîtrise en info. C'est l'un, ou c'est l'autre - tu ne peux pas embaucher "un testeur" dans l'abstrait.
Laurent http://bossavit.com/thoughts/
Super exemple, celui là je vais le noter...
Pour aller plus loin:
Tu as engagé les 2 testeur2, Bob et Marla.
Tu sais que Bob trouve vite les failles mais remplit lentement les rapports de bug, alors que Marla c'est le contraire.
Et bien selon le projet et ton besoin tu vas affecter Bob ou Marla à ton projet (alors que les deux sont capables de faire le travail...)
-Patrick
"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1c7b0378c6365a399898d2@news.noos.fr...
Manu,
List maList = new ArrayList();
C'est la même différence qu'il existe entre un poste et une personne.
Imagine que tu es un chef de projet, et que tu veux embaucher, disons,
un testeur. Pour ce poste, tu vas définir des responsabilités précises;
un testeur doit savoir trouver des failles, remplir un rapport de bug,
collaborer avec les développeurs au moment de la résolution, etc. Lors
de l'embauche, il est rédhibitoire que la personne ne dispose pas de ces
compétences.
Par contre, il t'indiffère de savoir si ton candidat est un homme ou une
femme, s'il a appris à tester par correspondance ou à l'école, si sa
première langue est l'anglais, le français ou le tchèque, et tout un tas
de choses qui ne sont pas pertinentes quant à sa capacité à effectuer le
travail.
Cependant, il faut bien qu'à un moment donné tu embauches un testeur
*précis*; que tu choisisses entre Bob, 6 ans d'expérience dans le jeu
vidéo, autodidacte, et Marla, 4 ans d'expérience dans la banque,
titulaire d'une maîtrise en info. C'est l'un, ou c'est l'autre - tu ne
peux pas embaucher "un testeur" dans l'abstrait.
Laurent
http://bossavit.com/thoughts/
Super exemple, celui là je vais le noter...
Pour aller plus loin:
Tu as engagé les 2 testeur2, Bob et Marla.
Tu sais que Bob trouve vite les failles mais remplit lentement les rapports
de bug, alors que Marla c'est le contraire.
Et bien selon le projet et ton besoin tu vas affecter Bob ou Marla à ton
projet (alors que les deux sont capables de faire le travail...)
C'est la même différence qu'il existe entre un poste et une personne.
Imagine que tu es un chef de projet, et que tu veux embaucher, disons, un testeur. Pour ce poste, tu vas définir des responsabilités précises; un testeur doit savoir trouver des failles, remplir un rapport de bug, collaborer avec les développeurs au moment de la résolution, etc. Lors de l'embauche, il est rédhibitoire que la personne ne dispose pas de ces compétences.
Par contre, il t'indiffère de savoir si ton candidat est un homme ou une femme, s'il a appris à tester par correspondance ou à l'école, si sa première langue est l'anglais, le français ou le tchèque, et tout un tas de choses qui ne sont pas pertinentes quant à sa capacité à effectuer le travail.
Cependant, il faut bien qu'à un moment donné tu embauches un testeur *précis*; que tu choisisses entre Bob, 6 ans d'expérience dans le jeu vidéo, autodidacte, et Marla, 4 ans d'expérience dans la banque, titulaire d'une maîtrise en info. C'est l'un, ou c'est l'autre - tu ne peux pas embaucher "un testeur" dans l'abstrait.
Laurent http://bossavit.com/thoughts/
Super exemple, celui là je vais le noter...
Pour aller plus loin:
Tu as engagé les 2 testeur2, Bob et Marla.
Tu sais que Bob trouve vite les failles mais remplit lentement les rapports de bug, alors que Marla c'est le contraire.
Et bien selon le projet et ton besoin tu vas affecter Bob ou Marla à ton projet (alors que les deux sont capables de faire le travail...)
-Patrick
Wismerhill
Manu ecrivit le 14/02/2005 13:20 :
bonjour, je n'arrive pas encore a assimuler le concept de ceci : List maList = new ArrayList(); au lieu de : ArrayList maList = new ArrayList(); (valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
Ca te permet de changer plus tard librement l'implementation technique de ta liste (ArrayList), sans devoir changer le type de ta variable (List).
Demain, tu pourras modifier ton code ainsi:
List maList = new LinkedList();
sans rien retoucher de tout ton code qui utilise ta variable maList, car le type de ta variable reste le même: List. La raison de tout ça ? ArrayList and LinkedList n'ont pas la même implémentation, ça signifie qu'elles n'ont pas les même temps de réponse selon les opérations demandées (accès séquentiel, aléatoire, ajout, effacement, etc). Selon les besoins de ton application, tu dois choisir l'implementation qui convient le mieux et le principe exposé au-dessus (séparation interface/implémentation) te permet de changer l'implémentation de manière transparente pour le reste de ton code.
Dans le même esprit, tu pourrais écrire aussi:
Voiture maVoiture = new Super5();
et demain tu pourras changer en
Voiture maVoiture = new BMW();
Manu ecrivit le 14/02/2005 13:20 :
bonjour,
je n'arrive pas encore a assimuler le concept de ceci :
List maList = new ArrayList();
au lieu de :
ArrayList maList = new ArrayList();
(valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
Ca te permet de changer plus tard librement l'implementation technique
de ta liste (ArrayList), sans devoir changer le type de ta variable
(List).
Demain, tu pourras modifier ton code ainsi:
List maList = new LinkedList();
sans rien retoucher de tout ton code qui utilise ta variable maList,
car le type de ta variable reste le même: List. La raison de tout ça ?
ArrayList and LinkedList n'ont pas la même implémentation, ça signifie
qu'elles n'ont pas les même temps de réponse selon les opérations
demandées (accès séquentiel, aléatoire, ajout, effacement, etc). Selon
les besoins de ton application, tu dois choisir l'implementation qui
convient le mieux et le principe exposé au-dessus (séparation
interface/implémentation) te permet de changer l'implémentation de
manière transparente pour le reste de ton code.
bonjour, je n'arrive pas encore a assimuler le concept de ceci : List maList = new ArrayList(); au lieu de : ArrayList maList = new ArrayList(); (valable pour n'importe qu'elle autre interface / classe ...)
si quelqu'un a une explication explicite :)
Ca te permet de changer plus tard librement l'implementation technique de ta liste (ArrayList), sans devoir changer le type de ta variable (List).
Demain, tu pourras modifier ton code ainsi:
List maList = new LinkedList();
sans rien retoucher de tout ton code qui utilise ta variable maList, car le type de ta variable reste le même: List. La raison de tout ça ? ArrayList and LinkedList n'ont pas la même implémentation, ça signifie qu'elles n'ont pas les même temps de réponse selon les opérations demandées (accès séquentiel, aléatoire, ajout, effacement, etc). Selon les besoins de ton application, tu dois choisir l'implementation qui convient le mieux et le principe exposé au-dessus (séparation interface/implémentation) te permet de changer l'implémentation de manière transparente pour le reste de ton code.
