Je débarque dans le monde de java alors merci d'être un peu indulgent si mes
questions vous paraissent un peu légères...
Bon, je me lance...
En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette
méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé
"const".
ex avec un accesseur :
int MaClasse::GetValue() const
{
return _nValue; // _nValue étant une donnée membre de ma classe.
}
Ma question : existe-t'il un équivalent en java permettant de vérouiller une
méthode de classe pour s'assurer que l'objet ne sera pas modifié ?
Bon, je me lance... En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé "const".
Pour Java oublie cette anomalie temporelle que fut le C++ et recrée toi une pensée neuve.
Bon, je me lance...
En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette
méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé
"const".
Pour Java oublie cette anomalie temporelle que fut le C++ et recrée toi
une pensée neuve.
Bon, je me lance... En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé "const".
Pour Java oublie cette anomalie temporelle que fut le C++ et recrée toi une pensée neuve.
captainpaf
Unknown a exposé le 25/05/2004 :
Bon, je me lance... En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé "const".
Pour Java oublie cette anomalie temporelle que fut le C++ et recrée toi une pensée neuve.
Pff, ça c'est vraiment une réponse de merde. Ta raison de te cacher !
Unknown a exposé le 25/05/2004 :
Bon, je me lance...
En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette
méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé
"const".
Pour Java oublie cette anomalie temporelle que fut le C++ et recrée toi
une pensée neuve.
Pff, ça c'est vraiment une réponse de merde. Ta raison de te cacher !
Bon, je me lance... En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé "const".
Pour Java oublie cette anomalie temporelle que fut le C++ et recrée toi une pensée neuve.
Pff, ça c'est vraiment une réponse de merde. Ta raison de te cacher !
captainpaf
Il se trouve que Chewee a formulé :
Bonjour tout le monde...
Je débarque dans le monde de java alors merci d'être un peu indulgent si mes questions vous paraissent un peu légères...
Bon, je me lance... En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé "const".
ex avec un accesseur :
int MaClasse::GetValue() const { return _nValue; // _nValue étant une donnée membre de ma classe. }
Ma question : existe-t'il un équivalent en java permettant de vérouiller une méthode de classe pour s'assurer que l'objet ne sera pas modifié ?
Merci d'avance... Chewee
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Il se trouve que Chewee a formulé :
Bonjour tout le monde...
Je débarque dans le monde de java alors merci d'être un peu indulgent si mes
questions vous paraissent un peu légères...
Bon, je me lance...
En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette
méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé
"const".
ex avec un accesseur :
int MaClasse::GetValue() const
{
return _nValue; // _nValue étant une donnée membre de ma classe.
}
Ma question : existe-t'il un équivalent en java permettant de vérouiller une
méthode de classe pour s'assurer que l'objet ne sera pas modifié ?
Merci d'avance...
Chewee
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas
modifier l'instance d'un objet. Il existe quand même un moyen de
s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci
te garantie qu'aucune méthode ne pourra modifier cette objet.
Je débarque dans le monde de java alors merci d'être un peu indulgent si mes questions vous paraissent un peu légères...
Bon, je me lance... En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé "const".
ex avec un accesseur :
int MaClasse::GetValue() const { return _nValue; // _nValue étant une donnée membre de ma classe. }
Ma question : existe-t'il un équivalent en java permettant de vérouiller une méthode de classe pour s'assurer que l'objet ne sera pas modifié ?
Merci d'avance... Chewee
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
no.bcausse.spam
captainpaf wrote:
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
non, final marque la reference mais pas l'objet lui meme
final obj = new Obj(); //modification de lobjet obj.setAttr(x); // est autorisé //modification de la ref obj = new Obj(); // n'est pas autorisé
-- bruno Causse http://perso.wanadoo.fr/othello
captainpaf <invalid@invalid.fr> wrote:
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas
modifier l'instance d'un objet. Il existe quand même un moyen de
s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci
te garantie qu'aucune méthode ne pourra modifier cette objet.
non, final marque la reference mais pas l'objet lui meme
final obj = new Obj();
//modification de lobjet
obj.setAttr(x); // est autorisé
//modification de la ref
obj = new Obj(); // n'est pas autorisé
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
non, final marque la reference mais pas l'objet lui meme
final obj = new Obj(); //modification de lobjet obj.setAttr(x); // est autorisé //modification de la ref obj = new Obj(); // n'est pas autorisé
-- bruno Causse http://perso.wanadoo.fr/othello
captainpaf
Causse Bruno avait écrit le 25/05/2004 :
captainpaf wrote:
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
non, final marque la reference mais pas l'objet lui meme
final obj = new Obj(); //modification de lobjet obj.setAttr(x); // est autorisé //modification de la ref obj = new Obj(); // n'est pas autorisé
oui bien sûr, c'est à toi de controler qu'il n'existe pas de méthode dans l'object permettant de modifier ses attributs. Merci de l'avoir précisé.
Causse Bruno avait écrit le 25/05/2004 :
captainpaf <invalid@invalid.fr> wrote:
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas
modifier l'instance d'un objet. Il existe quand même un moyen de
s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci
te garantie qu'aucune méthode ne pourra modifier cette objet.
non, final marque la reference mais pas l'objet lui meme
final obj = new Obj();
//modification de lobjet
obj.setAttr(x); // est autorisé
//modification de la ref
obj = new Obj(); // n'est pas autorisé
oui bien sûr, c'est à toi de controler qu'il n'existe pas de méthode
dans l'object permettant de modifier ses attributs. Merci de l'avoir
précisé.
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
non, final marque la reference mais pas l'objet lui meme
final obj = new Obj(); //modification de lobjet obj.setAttr(x); // est autorisé //modification de la ref obj = new Obj(); // n'est pas autorisé
oui bien sûr, c'est à toi de controler qu'il n'existe pas de méthode dans l'object permettant de modifier ses attributs. Merci de l'avoir précisé.
Chewee
captainpaf wrote:
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Merci, mais ce n'est pas exactement ce que je cherche. Je voudrais juste pouvoir vérouiller certaines méthodes (Getter) et bien entendu laisser à d'autres la possibilité de modifier l'objet (Setter). Mais bon, ce n'est pas non plus une fonctionalité indispensable, ça permet juste de faire du code un peu plus clean et éviter les erreurs (par effets de bord...).
Je pense que je reviendrais vers vous de temps en temps quand j'aurais d'autres questions, mais je ne pourrais m'empècher de faire le parallèle avec le C++, quitte à déplaire à certains...
Merci en tout cas. A+
captainpaf wrote:
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas
modifier l'instance d'un objet. Il existe quand même un moyen de
s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci
te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Merci, mais ce n'est pas exactement ce que je cherche.
Je voudrais juste pouvoir vérouiller certaines méthodes (Getter) et bien
entendu laisser à d'autres la possibilité de modifier l'objet (Setter).
Mais bon, ce n'est pas non plus une fonctionalité indispensable, ça permet
juste de faire du code un peu plus clean et éviter les erreurs (par effets
de bord...).
Je pense que je reviendrais vers vous de temps en temps quand j'aurais
d'autres questions, mais je ne pourrais m'empècher de faire le parallèle
avec le C++, quitte à déplaire à certains...
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Merci, mais ce n'est pas exactement ce que je cherche. Je voudrais juste pouvoir vérouiller certaines méthodes (Getter) et bien entendu laisser à d'autres la possibilité de modifier l'objet (Setter). Mais bon, ce n'est pas non plus une fonctionalité indispensable, ça permet juste de faire du code un peu plus clean et éviter les erreurs (par effets de bord...).
Je pense que je reviendrais vers vous de temps en temps quand j'aurais d'autres questions, mais je ne pourrais m'empècher de faire le parallèle avec le C++, quitte à déplaire à certains...
Merci en tout cas. A+
captainpaf
captainpaf wrote:
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Merci, mais ce n'est pas exactement ce que je cherche. Je voudrais juste pouvoir vérouiller certaines méthodes (Getter) et bien entendu laisser à d'autres la possibilité de modifier l'objet (Setter). Mais bon, ce n'est pas non plus une fonctionalité indispensable, ça permet juste de faire du code un peu plus clean et éviter les erreurs (par effets de bord...).
Je pense que je reviendrais vers vous de temps en temps quand j'aurais d'autres questions, mais je ne pourrais m'empècher de faire le parallèle avec le C++, quitte à déplaire à certains...
Merci en tout cas. A+
Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas forcément). Tu mets un getter public mais au lieu de retourner une référence vers l'attribut de l'objet il retourne une nouvelle référence identique (voir clone())à celle de l'attribut. Ainsi les modifications ne seront pas reportées au niveau de l'objet de départ. Et pour les setter, il suffit de jouer sur la visibilité.
Je préfère vraiment éviter ce genre de chose car si tu dois modifier un élément récupérer à l'aide d'un getter, c'est sûrement que tu as un problème de conception. Donc peut être vaut il mieux repenser ta conception.
captainpaf wrote:
Salut et bienvenue dans le monde java,
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas
modifier l'instance d'un objet. Il existe quand même un moyen de
s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci
te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Merci, mais ce n'est pas exactement ce que je cherche.
Je voudrais juste pouvoir vérouiller certaines méthodes (Getter) et bien
entendu laisser à d'autres la possibilité de modifier l'objet (Setter).
Mais bon, ce n'est pas non plus une fonctionalité indispensable, ça permet
juste de faire du code un peu plus clean et éviter les erreurs (par effets
de bord...).
Je pense que je reviendrais vers vous de temps en temps quand j'aurais
d'autres questions, mais je ne pourrais m'empècher de faire le parallèle
avec le C++, quitte à déplaire à certains...
Merci en tout cas.
A+
Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas
forcément). Tu mets un getter public mais au lieu de retourner une
référence vers l'attribut de l'objet il retourne une nouvelle référence
identique (voir clone())à celle de l'attribut.
Ainsi les modifications ne seront pas reportées au niveau de l'objet de
départ.
Et pour les setter, il suffit de jouer sur la visibilité.
Je préfère vraiment éviter ce genre de chose car si tu dois modifier un
élément récupérer à l'aide d'un getter, c'est sûrement que tu as un
problème de conception. Donc peut être vaut il mieux repenser ta
conception.
non, ça n'existe pas en java. Un "getter" ne doit (normalement) pas modifier l'instance d'un objet. Il existe quand même un moyen de s'assurer qu'un attribut n'est pas modifié en utilisant "final". Ceci te garantie qu'aucune méthode ne pourra modifier cette objet.
bonne continuation.
Merci, mais ce n'est pas exactement ce que je cherche. Je voudrais juste pouvoir vérouiller certaines méthodes (Getter) et bien entendu laisser à d'autres la possibilité de modifier l'objet (Setter). Mais bon, ce n'est pas non plus une fonctionalité indispensable, ça permet juste de faire du code un peu plus clean et éviter les erreurs (par effets de bord...).
Je pense que je reviendrais vers vous de temps en temps quand j'aurais d'autres questions, mais je ne pourrais m'empècher de faire le parallèle avec le C++, quitte à déplaire à certains...
Merci en tout cas. A+
Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas forcément). Tu mets un getter public mais au lieu de retourner une référence vers l'attribut de l'objet il retourne une nouvelle référence identique (voir clone())à celle de l'attribut. Ainsi les modifications ne seront pas reportées au niveau de l'objet de départ. Et pour les setter, il suffit de jouer sur la visibilité.
Je préfère vraiment éviter ce genre de chose car si tu dois modifier un élément récupérer à l'aide d'un getter, c'est sûrement que tu as un problème de conception. Donc peut être vaut il mieux repenser ta conception.
Chewee
captainpaf wrote:
Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas forcément). Tu mets un getter public mais au lieu de retourner une référence vers l'attribut de l'objet il retourne une nouvelle référence identique (voir clone())à celle de l'attribut. Ainsi les modifications ne seront pas reportées au niveau de l'objet de départ. Et pour les setter, il suffit de jouer sur la visibilité.
Ta méthode marche, mais là c'est carrément sous-optimal. Je ne vais pas dupliquer tout mon objet à chaque fois que j'utilise un accesseur...
Je préfère vraiment éviter ce genre de chose car si tu dois modifier un élément récupérer à l'aide d'un getter, c'est sûrement que tu as un problème de conception. Donc peut être vaut il mieux repenser ta conception.
Il est évident que ce que je demandais vise à éviter les problêmes de conceptions. En C++, une methode dite const qui modifie une donnée membre de la classe entrainera une erreur de compilation alors ça évite tout soucis...
captainpaf wrote:
Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas
forcément). Tu mets un getter public mais au lieu de retourner une
référence vers l'attribut de l'objet il retourne une nouvelle
référence identique (voir clone())à celle de l'attribut.
Ainsi les modifications ne seront pas reportées au niveau de l'objet
de départ.
Et pour les setter, il suffit de jouer sur la visibilité.
Ta méthode marche, mais là c'est carrément sous-optimal.
Je ne vais pas dupliquer tout mon objet à chaque fois que j'utilise un
accesseur...
Je préfère vraiment éviter ce genre de chose car si tu dois modifier
un élément récupérer à l'aide d'un getter, c'est sûrement que tu as un
problème de conception. Donc peut être vaut il mieux repenser ta
conception.
Il est évident que ce que je demandais vise à éviter les problêmes de
conceptions.
En C++, une methode dite const qui modifie une donnée membre de la classe
entrainera une erreur de compilation alors ça évite tout soucis...
Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas forcément). Tu mets un getter public mais au lieu de retourner une référence vers l'attribut de l'objet il retourne une nouvelle référence identique (voir clone())à celle de l'attribut. Ainsi les modifications ne seront pas reportées au niveau de l'objet de départ. Et pour les setter, il suffit de jouer sur la visibilité.
Ta méthode marche, mais là c'est carrément sous-optimal. Je ne vais pas dupliquer tout mon objet à chaque fois que j'utilise un accesseur...
Je préfère vraiment éviter ce genre de chose car si tu dois modifier un élément récupérer à l'aide d'un getter, c'est sûrement que tu as un problème de conception. Donc peut être vaut il mieux repenser ta conception.
Il est évident que ce que je demandais vise à éviter les problêmes de conceptions. En C++, une methode dite const qui modifie une donnée membre de la classe entrainera une erreur de compilation alors ça évite tout soucis...
Unknown
Pff, ça c'est vraiment une réponse de merde. Ta raison de te cacher !
et bé, je vais demander à la création d'un fr.comp.lang.java.humour :)
Pff, ça c'est vraiment une réponse de merde. Ta raison de te cacher !
et bé, je vais demander à la création d'un fr.comp.lang.java.humour :)
