Le 05.08 2003, Kupee s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pis il est aussi possible de coder comme un cochon en java. La preuve, regardez dans les facs le nombre d'étudiants qui vont faire un projet avec tout static et pas du tout objet ....
On le trouve aussi chez des tonnes d'ingénieur qui codent tout avec d'un côté les classes contenant les données, et de l'autre les managers static... Et c'est malheureusement un design qui se répand.
-- Nicolas Delsaux Tu as des poils qui te poussent partout sur le corps ? Ta bibliothèque est plus grande à l'intérieur qu'à l'extérieur ? Et pire que tout, tu commences toutes tes phrases par Oo en les terminant par kkkk ? Pas de doute, tu te transformes en bibliothécaire de l'université invisible.
Le 05.08 2003, Kupee <abc@hotmail.com> s'est levé(e) et s'est dit "tiens,
je vais écrire aux mecs de fr.comp.lang.java"
Pis il est aussi possible de coder comme un cochon en java. La preuve,
regardez dans les facs le nombre d'étudiants qui vont faire un projet
avec tout static et pas du tout objet ....
On le trouve aussi chez des tonnes d'ingénieur qui codent tout avec d'un
côté les classes contenant les données, et de l'autre les managers
static...
Et c'est malheureusement un design qui se répand.
--
Nicolas Delsaux
Tu as des poils qui te poussent partout sur le corps ?
Ta bibliothèque est plus grande à l'intérieur qu'à l'extérieur ?
Et pire que tout, tu commences toutes tes phrases par Oo en les terminant
par kkkk ?
Pas de doute, tu te transformes en bibliothécaire de l'université
invisible.
Le 05.08 2003, Kupee s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pis il est aussi possible de coder comme un cochon en java. La preuve, regardez dans les facs le nombre d'étudiants qui vont faire un projet avec tout static et pas du tout objet ....
On le trouve aussi chez des tonnes d'ingénieur qui codent tout avec d'un côté les classes contenant les données, et de l'autre les managers static... Et c'est malheureusement un design qui se répand.
-- Nicolas Delsaux Tu as des poils qui te poussent partout sur le corps ? Ta bibliothèque est plus grande à l'intérieur qu'à l'extérieur ? Et pire que tout, tu commences toutes tes phrases par Oo en les terminant par kkkk ? Pas de doute, tu te transformes en bibliothécaire de l'université invisible.
Raphaël Piéroni
Nicolas Delsaux wrote:
Le 05.08 2003, Kupee s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pis il est aussi possible de coder comme un cochon en java. La preuve, regardez dans les facs le nombre d'étudiants qui vont faire un projet avec tout static et pas du tout objet ....
On le trouve aussi chez des tonnes d'ingénieur qui codent tout avec d'un côté les classes contenant les données, et de l'autre les managers static... Et c'est malheureusement un design qui se répand.
si les methodes static etaient a proscrire, elle ne feraient meme pas
parti du langage. pour info, les equipes jakarta, dont on ne peut pas douter de leur connaissance de l'objet utilisent aussi des methodes statiques. mais pas pour tout faire. de temps en temps, cela se justifie. lorsque par exemple on a un petit bout de code qui peut etre utilisé souvent, mais qui n'a sa place dans aucune classe.
de plus quelle est la différence réelle entre un singleton et une classe dont toutes les methodes sont statiques ?
R
Nicolas Delsaux wrote:
Le 05.08 2003, Kupee <abc@hotmail.com> s'est levé(e) et s'est dit "tiens,
je vais écrire aux mecs de fr.comp.lang.java"
Pis il est aussi possible de coder comme un cochon en java. La preuve,
regardez dans les facs le nombre d'étudiants qui vont faire un projet
avec tout static et pas du tout objet ....
On le trouve aussi chez des tonnes d'ingénieur qui codent tout avec d'un
côté les classes contenant les données, et de l'autre les managers
static...
Et c'est malheureusement un design qui se répand.
si les methodes static etaient a proscrire, elle ne feraient meme pas
parti du langage.
pour info, les equipes jakarta, dont on ne peut pas douter de leur
connaissance de l'objet utilisent aussi des methodes statiques. mais pas
pour tout faire. de temps en temps, cela se justifie. lorsque par
exemple on a un petit bout de code qui peut etre utilisé souvent, mais
qui n'a sa place dans aucune classe.
de plus quelle est la différence réelle entre un singleton et une classe
dont toutes les methodes sont statiques ?
Le 05.08 2003, Kupee s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pis il est aussi possible de coder comme un cochon en java. La preuve, regardez dans les facs le nombre d'étudiants qui vont faire un projet avec tout static et pas du tout objet ....
On le trouve aussi chez des tonnes d'ingénieur qui codent tout avec d'un côté les classes contenant les données, et de l'autre les managers static... Et c'est malheureusement un design qui se répand.
si les methodes static etaient a proscrire, elle ne feraient meme pas
parti du langage. pour info, les equipes jakarta, dont on ne peut pas douter de leur connaissance de l'objet utilisent aussi des methodes statiques. mais pas pour tout faire. de temps en temps, cela se justifie. lorsque par exemple on a un petit bout de code qui peut etre utilisé souvent, mais qui n'a sa place dans aucune classe.
de plus quelle est la différence réelle entre un singleton et une classe dont toutes les methodes sont statiques ?
R
Dominique Marie
Kupee wrote:
D'ailleurs moi qui suis autodidacte pour ce qui est de la prog objet, j'ai constaté que souvent dans une classe une méthode peut soit prendre des paramètres et retourner une valeur, soit lire des champs et en modifier d'autres, pour obtenir le meme fonctionnement. Et si on choisit d'utiliser des paramètres et une valeur de retour, il arrive souvent que la méthode puisse etre static. C'est mal ? Cela gene t'il quelque chose ? Ya t'il une raison d'utiliser une méthode plutot qu'une autre ?
non statique == méthode d'instance. statique == méthode de classe.
une méthode d'instance sert en principe à manipuler les données encapsulées par un objet, par exemple : - les accesseurs ; - translation d'un objet représentant un point.
une méthode de classe sert en principe à manipuler des données communes à toutes les instances d'une classe, par exemple : - un compteur d'instances ; - des valeurs constantes. on peut aussi s'en servir pour certains patterns comme le Singleton pour fournir l'instance partagée...
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Kupee wrote:
D'ailleurs moi qui suis autodidacte pour ce qui est de la prog objet,
j'ai constaté que souvent dans une classe une méthode peut soit prendre
des paramètres et retourner une valeur, soit lire des champs et en
modifier d'autres, pour obtenir le meme fonctionnement.
Et si on choisit d'utiliser des paramètres et une valeur de retour, il
arrive souvent que la méthode puisse etre static.
C'est mal ? Cela gene t'il quelque chose ? Ya t'il une raison d'utiliser
une méthode plutot qu'une autre ?
non statique == méthode d'instance.
statique == méthode de classe.
une méthode d'instance sert en principe à manipuler les données encapsulées
par un objet, par exemple :
- les accesseurs ;
- translation d'un objet représentant un point.
une méthode de classe sert en principe à manipuler des données communes à
toutes les instances d'une classe, par exemple :
- un compteur d'instances ;
- des valeurs constantes.
on peut aussi s'en servir pour certains patterns comme le Singleton pour
fournir l'instance partagée...
--
Dominique
remplacer nospam par com dans mon adresse pour m'écrire
D'ailleurs moi qui suis autodidacte pour ce qui est de la prog objet, j'ai constaté que souvent dans une classe une méthode peut soit prendre des paramètres et retourner une valeur, soit lire des champs et en modifier d'autres, pour obtenir le meme fonctionnement. Et si on choisit d'utiliser des paramètres et une valeur de retour, il arrive souvent que la méthode puisse etre static. C'est mal ? Cela gene t'il quelque chose ? Ya t'il une raison d'utiliser une méthode plutot qu'une autre ?
non statique == méthode d'instance. statique == méthode de classe.
une méthode d'instance sert en principe à manipuler les données encapsulées par un objet, par exemple : - les accesseurs ; - translation d'un objet représentant un point.
une méthode de classe sert en principe à manipuler des données communes à toutes les instances d'une classe, par exemple : - un compteur d'instances ; - des valeurs constantes. on peut aussi s'en servir pour certains patterns comme le Singleton pour fournir l'instance partagée...
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Dominique Marie
Raphaël Piéroni wrote:
de plus quelle est la différence réelle entre un singleton et une classe dont toutes les methodes sont statiques ?
tu dis adieu à l'héritage...
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Raphaël Piéroni wrote:
de plus quelle est la différence réelle entre un singleton et une classe
dont toutes les methodes sont statiques ?
tu dis adieu à l'héritage...
--
Dominique
remplacer nospam par com dans mon adresse pour m'écrire
de plus quelle est la différence réelle entre un singleton et une classe dont toutes les methodes sont statiques ?
tu dis adieu à l'héritage...
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Kupee
Dominique Marie wrote:
non statique == méthode d'instance. statique == méthode de classe.
une méthode d'instance sert en principe à manipuler les données encapsulées par un objet, par exemple : - les accesseurs ; - translation d'un objet représentant un point.
une méthode de classe sert en principe à manipuler des données communes à toutes les instances d'une classe, par exemple : - un compteur d'instances ; - des valeurs constantes. on peut aussi s'en servir pour certains patterns comme le Singleton pour fournir l'instance partagée...
Je sais tout ca mais imagine ca : public class MonPanel extends Panel { private Label label;
public MonPanel(String name) { label = creeLabel(name); add(label); }
private Label creeLabel(String name) { return new Label(name); } }
dans ce cas creeLabel pourrait aussi bien etre static on peut aussi faire ca :
public class MonPanel extends Panel { private Label label; private String name;
public MonPanel(String name) { this.name = name; creeLabel(); add(label); }
yen a un qu'est mieux que l'autre ? avec des raisons objectives ou juste question de gouts ?
Dominique Marie wrote:
non statique == méthode d'instance.
statique == méthode de classe.
une méthode d'instance sert en principe à manipuler les données encapsulées
par un objet, par exemple :
- les accesseurs ;
- translation d'un objet représentant un point.
une méthode de classe sert en principe à manipuler des données communes à
toutes les instances d'une classe, par exemple :
- un compteur d'instances ;
- des valeurs constantes.
on peut aussi s'en servir pour certains patterns comme le Singleton pour
fournir l'instance partagée...
Je sais tout ca mais imagine ca :
public class MonPanel extends Panel {
private Label label;
public MonPanel(String name) {
label = creeLabel(name);
add(label);
}
private Label creeLabel(String name) {
return new Label(name);
}
}
dans ce cas creeLabel pourrait aussi bien etre static
on peut aussi faire ca :
public class MonPanel extends Panel {
private Label label;
private String name;
public MonPanel(String name) {
this.name = name;
creeLabel();
add(label);
}
non statique == méthode d'instance. statique == méthode de classe.
une méthode d'instance sert en principe à manipuler les données encapsulées par un objet, par exemple : - les accesseurs ; - translation d'un objet représentant un point.
une méthode de classe sert en principe à manipuler des données communes à toutes les instances d'une classe, par exemple : - un compteur d'instances ; - des valeurs constantes. on peut aussi s'en servir pour certains patterns comme le Singleton pour fournir l'instance partagée...
Je sais tout ca mais imagine ca : public class MonPanel extends Panel { private Label label;
public MonPanel(String name) { label = creeLabel(name); add(label); }
private Label creeLabel(String name) { return new Label(name); } }
dans ce cas creeLabel pourrait aussi bien etre static on peut aussi faire ca :
public class MonPanel extends Panel { private Label label; private String name;
public MonPanel(String name) { this.name = name; creeLabel(); add(label); }
yen a un qu'est mieux que l'autre ? avec des raisons objectives ou juste question de gouts ?
Kupee
Vincent wrote:
C'est la différence entre une procédure et une fonction. Imaginons que l'on a un objet voiture avec les méthodes - avancer(nbKm, boolean aPuAvancer) - kilométrage() - tourner(Direction d, boolean aPuTourner)
C'est assez naturel de dire que les méthodes avancer et tourner sont des procédures. Elles *font une action* : elles agissent sur l'objet et en modifient son état. C'est le principe d'une procédure. Elles ont des paramètres de compte-rendu de leur action (ici 'aPuAvancer' et 'aPuTourner').
Euh j'ai du mal a comprendre a quoi pourrait bien servir les paramètres aPuTourner ou aPuAvancer ... Si c'est pour dire qu'on peut pas tourner autant ne pas appeler la méthode carrément. Si c'est pour informer qu'on a tourné ou qu'on a pas pu, ca risque pas de marcher comme ca ...
Vincent wrote:
C'est la différence entre une procédure et une fonction.
Imaginons que l'on a un objet voiture avec les méthodes
- avancer(nbKm, boolean aPuAvancer)
- kilométrage()
- tourner(Direction d, boolean aPuTourner)
C'est assez naturel de dire que les méthodes avancer et tourner sont des
procédures. Elles *font une action* : elles agissent sur l'objet et en
modifient son état. C'est le principe d'une procédure. Elles ont des
paramètres de compte-rendu de leur action (ici 'aPuAvancer' et
'aPuTourner').
Euh j'ai du mal a comprendre a quoi pourrait bien servir les paramètres
aPuTourner ou aPuAvancer ...
Si c'est pour dire qu'on peut pas tourner autant ne pas appeler la
méthode carrément. Si c'est pour informer qu'on a tourné ou qu'on a pas
pu, ca risque pas de marcher comme ca ...
C'est la différence entre une procédure et une fonction. Imaginons que l'on a un objet voiture avec les méthodes - avancer(nbKm, boolean aPuAvancer) - kilométrage() - tourner(Direction d, boolean aPuTourner)
C'est assez naturel de dire que les méthodes avancer et tourner sont des procédures. Elles *font une action* : elles agissent sur l'objet et en modifient son état. C'est le principe d'une procédure. Elles ont des paramètres de compte-rendu de leur action (ici 'aPuAvancer' et 'aPuTourner').
Euh j'ai du mal a comprendre a quoi pourrait bien servir les paramètres aPuTourner ou aPuAvancer ... Si c'est pour dire qu'on peut pas tourner autant ne pas appeler la méthode carrément. Si c'est pour informer qu'on a tourné ou qu'on a pas pu, ca risque pas de marcher comme ca ...
Vincent
Kupee a pris sa plume et, dans le message
Si c'est pour informer qu'on a tourné ou qu'on a pas pu, ca risque pas de marcher comme ca ...
Pourquoi donc cela ne pourrait-il pas marcher? Tu peux très bien avoir un objet qui contient le résultat de ton action. Pour continuer sur l'exemple de la voiture, imaginons un résultat ayant cette structure là : CompteRendu
boolean actionTerminee; int angleReelDeRotation; // la voiture a tourné réellement de seulement 'angleReelDeRotation' degrés }
Pourquoi donc cela n'est-il pas possible? ah, je viens de comprendre, c'est parce que j'ai mis 'boolean', c'est ça? ok...
-- Vincent
Kupee a pris sa plume et, dans le message
Si c'est pour informer qu'on a tourné ou qu'on a
pas pu, ca risque pas de marcher comme ca ...
Pourquoi donc cela ne pourrait-il pas marcher? Tu peux très bien avoir
un objet qui contient le résultat de ton action. Pour continuer sur
l'exemple de la voiture, imaginons un résultat ayant cette structure là
:
CompteRendu
boolean actionTerminee;
int angleReelDeRotation; // la voiture a tourné réellement de
seulement 'angleReelDeRotation' degrés
}
Pourquoi donc cela n'est-il pas possible?
ah, je viens de comprendre, c'est parce que j'ai mis 'boolean', c'est
ça?
ok...
Si c'est pour informer qu'on a tourné ou qu'on a pas pu, ca risque pas de marcher comme ca ...
Pourquoi donc cela ne pourrait-il pas marcher? Tu peux très bien avoir un objet qui contient le résultat de ton action. Pour continuer sur l'exemple de la voiture, imaginons un résultat ayant cette structure là : CompteRendu
boolean actionTerminee; int angleReelDeRotation; // la voiture a tourné réellement de seulement 'angleReelDeRotation' degrés }
Pourquoi donc cela n'est-il pas possible? ah, je viens de comprendre, c'est parce que j'ai mis 'boolean', c'est ça? ok...
-- Vincent
Kupee
Vincent wrote:
Kupee a pris sa plume et, dans le message
Si c'est pour informer qu'on a tourné ou qu'on a pas pu, ca risque pas de marcher comme ca ...
Pourquoi donc cela ne pourrait-il pas marcher? Tu peux très bien avoir un objet qui contient le résultat de ton action. Pour continuer sur l'exemple de la voiture, imaginons un résultat ayant cette structure là : CompteRendu
boolean actionTerminee; int angleReelDeRotation; // la voiture a tourné réellement de seulement 'angleReelDeRotation' degrés }
Pourquoi donc cela n'est-il pas possible? ah, je viens de comprendre, c'est parce que j'ai mis 'boolean', c'est ça?
Ba oui un boolean ca passe pas par référence en paramètre donc on peut rien en faire. et un Boolean étant immuable ca n'aurait pas marché. Mais si tu passe un objet CompteRendu comme tu dis et que tu le modifie, alors oui ca devrait aller
Vincent wrote:
Kupee a pris sa plume et, dans le message
Si c'est pour informer qu'on a tourné ou qu'on a
pas pu, ca risque pas de marcher comme ca ...
Pourquoi donc cela ne pourrait-il pas marcher? Tu peux très bien avoir
un objet qui contient le résultat de ton action. Pour continuer sur
l'exemple de la voiture, imaginons un résultat ayant cette structure là
:
CompteRendu
boolean actionTerminee;
int angleReelDeRotation; // la voiture a tourné réellement de
seulement 'angleReelDeRotation' degrés
}
Pourquoi donc cela n'est-il pas possible?
ah, je viens de comprendre, c'est parce que j'ai mis 'boolean', c'est
ça?
Ba oui un boolean ca passe pas par référence en paramètre donc on peut
rien en faire. et un Boolean étant immuable ca n'aurait pas marché.
Mais si tu passe un objet CompteRendu comme tu dis et que tu le modifie,
alors oui ca devrait aller
Si c'est pour informer qu'on a tourné ou qu'on a pas pu, ca risque pas de marcher comme ca ...
Pourquoi donc cela ne pourrait-il pas marcher? Tu peux très bien avoir un objet qui contient le résultat de ton action. Pour continuer sur l'exemple de la voiture, imaginons un résultat ayant cette structure là : CompteRendu
boolean actionTerminee; int angleReelDeRotation; // la voiture a tourné réellement de seulement 'angleReelDeRotation' degrés }
Pourquoi donc cela n'est-il pas possible? ah, je viens de comprendre, c'est parce que j'ai mis 'boolean', c'est ça?
Ba oui un boolean ca passe pas par référence en paramètre donc on peut rien en faire. et un Boolean étant immuable ca n'aurait pas marché. Mais si tu passe un objet CompteRendu comme tu dis et que tu le modifie, alors oui ca devrait aller
Dominique Marie
Kupee wrote:
Je sais tout ca mais imagine ca : public class MonPanel extends Panel { private Label label;
public MonPanel(String name) { label = creeLabel(name); add(label); }
private Label creeLabel(String name) { return new Label(name); } }
dans ce cas creeLabel pourrait aussi bien etre static on peut aussi faire ca :
public class MonPanel extends Panel { private Label label; private String name;
public MonPanel(String name) { this.name = name; creeLabel(); add(label); }
yen a un qu'est mieux que l'autre ? avec des raisons objectives ou juste question de gouts ?
dans le premier cas static s'impose car la méthode ne dépend en rien d'une quelconque instance. C'est typiquement le cas de méthodes utilitaires que l'on place en privé dans le corps de la classe pour factoriser un peu de code.
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est le genre de macro-instructions que l'on crée, pour alléger le code du constructeur par exemple.
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Kupee wrote:
Je sais tout ca mais imagine ca :
public class MonPanel extends Panel {
private Label label;
public MonPanel(String name) {
label = creeLabel(name);
add(label);
}
private Label creeLabel(String name) {
return new Label(name);
}
}
dans ce cas creeLabel pourrait aussi bien etre static
on peut aussi faire ca :
public class MonPanel extends Panel {
private Label label;
private String name;
public MonPanel(String name) {
this.name = name;
creeLabel();
add(label);
}
yen a un qu'est mieux que l'autre ? avec des raisons objectives ou juste
question de gouts ?
dans le premier cas static s'impose car la méthode ne dépend en rien d'une
quelconque instance. C'est typiquement le cas de méthodes utilitaires que
l'on place en privé dans le corps de la classe pour factoriser un peu de
code.
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est
le genre de macro-instructions que l'on crée, pour alléger le code du
constructeur par exemple.
--
Dominique
remplacer nospam par com dans mon adresse pour m'écrire
yen a un qu'est mieux que l'autre ? avec des raisons objectives ou juste question de gouts ?
dans le premier cas static s'impose car la méthode ne dépend en rien d'une quelconque instance. C'est typiquement le cas de méthodes utilitaires que l'on place en privé dans le corps de la classe pour factoriser un peu de code.
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est le genre de macro-instructions que l'on crée, pour alléger le code du constructeur par exemple.
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Kupee
Dominique Marie wrote:
dans le premier cas static s'impose car la méthode ne dépend en rien d'une quelconque instance. C'est typiquement le cas de méthodes utilitaires que l'on place en privé dans le corps de la classe pour factoriser un peu de code.
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est le genre de macro-instructions que l'on crée, pour alléger le code du constructeur par exemple.
Enfin dans ce cas ca reste a peu près la meme chose, c'est un peu comme le bon chasseur et le mauvais chasseur non ?
Dominique Marie wrote:
dans le premier cas static s'impose car la méthode ne dépend en rien d'une
quelconque instance. C'est typiquement le cas de méthodes utilitaires que
l'on place en privé dans le corps de la classe pour factoriser un peu de
code.
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est
le genre de macro-instructions que l'on crée, pour alléger le code du
constructeur par exemple.
Enfin dans ce cas ca reste a peu près la meme chose, c'est un peu comme
le bon chasseur et le mauvais chasseur non ?
dans le premier cas static s'impose car la méthode ne dépend en rien d'une quelconque instance. C'est typiquement le cas de méthodes utilitaires que l'on place en privé dans le corps de la classe pour factoriser un peu de code.
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est le genre de macro-instructions que l'on crée, pour alléger le code du constructeur par exemple.
Enfin dans ce cas ca reste a peu près la meme chose, c'est un peu comme le bon chasseur et le mauvais chasseur non ?
