Discussion :

[Invité]

Bonjour à tous,

Je me demande s'il est possible, depuis une méthode statique, d'accéder à une propriété privée d'un objet.
J'ai une méthode statique qui doit être utilisée pour créer et persister un objet. En retour, j'attends l'objet crée avec toutes ses propriétés dont son identifiant (créé lors de la persistance). Cet identifiant n'étant pas modifiable, je le veux uniquement en lecture. Ce qui pose problème dans ma méthode de création. Mais je me dis qu'il est peut-être possible au sein d'une méthode statique d'accéder à une propriété privée étant donné qu'ils appartiennent au même objet...

Un peu de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
function Person(firstName, lastName) {
 
	var _id;
	var _firstName = firstName;
	var _lastName = lastName;
 
	this.getId = function() {
		return _id;
	}
 
	this.getFisrtName = function() {
		return _firstName;
	}
 
	this.toString = function() {
		return _firstName+' '+_lastName;
	}
}
 
Person.Create = function(firstName, lastName) {
        var rep = // Appel ajax au service qui renvoie les propriétés dans "rep"
	var created = new Person(rep.firstName, rep.lastName);
	created._id = rep.id;
	return created;
}

Or, lorsque j'affiche created.id j'obtiens "undefined"...

Merci pour votre aide.

[TheGwy]

Nop, impossible. Même dans un langage autre que JS tu ne pourrais pas d'ailleurs.

Le concept des variables privées c'est qu'elle contiennent des informations relatives à l'état interne (puisque privé) de ton objet. C'est totalement dépendant de ton instance, donc tes méthodes statiques n'ont rien à faire avec !

Pour faire simple, en Javascript ton scope est lexical :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
A{
   var private = true;
 
   B{
       alert(private); // true
   }
}
C{
   alert(private); // undefined
   alert(A.private); // undefined
}

Donc il est totalement impossible d'avoir un membre statique accedant à un membre privé.

[TheGwy]

Au lieu de faire une méthode pseudo-statique "Create", utilise plutôt un constructeur.

[p3ga5e]

Nop, impossible. Même dans un langage autre que JS tu ne pourrais pas d'ailleurs.

En faite dans d’autre langage Objet a base de class tel que c++, ou C# c’est possible :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class CPerson
{
private :
	int m_id;
	CPerson(void){}
 
public:
	~CPerson(void){}
 
	static CPerson* Create()
	{
		CPerson* p = new CPerson();
		p->m_id = 100;
		return p;
	}
};

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class Person
{
    private Guid m_id;
 
    public static Person Create()
    {
        Person p = new Person();
        p.m_id = Guid.NewGuid();
        return p;
    }
}

Le problème est que le hack utilisé par Blaise1, pour utiliser des membres privés, est vraiment a éviter, car tes variables _id, _firstName et _lastName ne sont pas encapsulés dans l’objet Person. Ils sont accessiblent uniquement dans les méthodes déclarés dans la fonction "constructeur".

Blaise1, je te déconseille cet méthode de déclaration, car tes objets ce limiteront a un simple hashtable de fonctions, et tu ne pouras pas utilisé des fonctions générique utilisant la réflexivité d’objet, comme par exemple des methodes de sérialisation d'objet.

[TheGwy]

@p3ga5e : au temps pour moi, je ne suis pas du tout fluent en C/C++

Pour ce qui est de ta remarque, je ne serai pas si catégorique.

Utiliser des closures comme il le fait à ce désavantage : illusion d'une visibilité "private" (ou encapsulation à l'instance de l'objet), alors que ce n'est qu'une visibilité lexicale; donc les méthodes d'instance doivent être dupliquées pour chaque instance si elles ont besoin d'accéder aux propriétés de l'instance.

Mais elles ont un avantage énorme qui est d'offrir une vraie protection en lecture. Ce qui est très important si tu fais du mashup, ou si tu dois maintenir du code sur la durée sur lequel beaucoup de devs sont susceptibles d'intervenir.

Pour ce qui est de chose comme la sérialisation cela peut toujours être résolu assez proprement avec une méthode d'instance serialize() qui elle aura accès au scope.

[p3ga5e]

tu sous-entend que c'est une pratique largement utilisé par les web developpeurs ?
vous n'encapuslez dans l'objet que les referance aux methodes et pas les données ?
etrange ! je suis pas sure que l'on puissent encore appeler ca un objet si celui-ci ne contient pas de données

pour information les compilateurs c++ font le contraire, le new sur un objet retourne une adresse sur allocation memoire contenant uniquement les données
les adresses sur les méthodes de l'objet sont contenus dans une structure , la VirtualTable, se trouvant a proximité mémoire de la référence sur l'objet, son emplacement depend du compilateur et elle n'est, normalement, pas accessible au developpeur c++
L'accessibilité au données membre sont, elles, verifiés uniquement a la phase de compilation.

Mais elles ont un avantage énorme qui est d'offrir une vraie protection en lecture

j'ai du mal a comprendre en quoi l'avantage est énorme par raport a la perte d'encapsulation des données, qui elle, est un désavantage énorme ... en meme temps je n'ai jamais bosser en combinaison avec différentes équipes de développement.

Pour ce qui est de chose comme la sérialisation cela peut toujours être résolu assez proprement avec une méthode d'instance serialize() qui elle aura accès au scope.

Si tu trouve ca propre je te conseille de te mettre aux C++, les architectures de logiciel en c++ sont souvent sur ce modèle la, bien que le c++ permet le développement générique avec les types template.
Personnellement je trouve rien de plus fustrant que de subir ce type d'architecture lorsque l'on utilise un langague supportant la réflexivité, surtout si cet restriction est liée a un simple problème d'accessibilité aux données membres
Sérieusement ce type d'architecture est moins productif, moins évolutif qu'une approche générique, pretendre le contraire relève du pur masochisme ^^

[TheGwy]

tu sous-entend que c'est une pratique largement utilisé par les web developpeurs ?
vous n'encapuslez dans l'objet que les referance aux methodes et pas les données ?
etrange ! je suis pas sure que l'on puissent encore appeler ca un objet si celui-ci ne contient pas de données

Hein quoi ?! J'ai jamais dis ça.

j'ai du mal a comprendre en quoi l'avantage est énorme par raport a la perte d'encapsulation des données, qui elle, est un désavantage énorme ... en meme temps je n'ai jamais bosser en combinaison avec différentes équipes de développement.

Bah non tu ne pers pas l'encapsulation, au contraire c'est le seul moyen d'en avoir en Javascript.


/me pense qu'on a des problèmes de communication tout les deux