Dans l'Application Block "Authorization and Profile", la classe
ExtendedPrincipal possède un attribut :
private StringCollection roles;
et une méthode qui renvoi les roles :
public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une
propriété ?
Avantages et inconvénients ?
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
Mitsuru FURUTA [Ms]
Bonjour,
Dans ce cas précis, je ne sais pas mais de mainère plus générale, c'est juste un avantage syntaxique. Au niveau de la compilation en IL, les accesseurs get et set d'une propriété génèrent des méthodes. Pour le get en tout cas, c'est donc exactement pareil. Pour le set par contre, c'est plus sympa puisqu'on bénéficie de l'écriture à gauche du " = " au lieu d'avoir à passer un paramètre. L'idée de toute façon est d'apporter la simplicité d'écriture d'une donnée membre toute simple mais en passant par des méthodes.
Bonne continuation,
Mitsuru FURUTA [Microsoft FRANCE]
"ShadowFil" wrote in message news:
Bonjour,
Dans l'Application Block "Authorization and Profile", la classe ExtendedPrincipal possède un attribut : private StringCollection roles; et une méthode qui renvoi les roles : public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une propriété ? Avantages et inconvénients ?
Merci pour votre aide.
Bonjour,
Dans ce cas précis, je ne sais pas mais de mainère plus générale, c'est
juste un avantage syntaxique.
Au niveau de la compilation en IL, les accesseurs get et set d'une propriété
génèrent des méthodes.
Pour le get en tout cas, c'est donc exactement pareil. Pour le set par
contre, c'est plus sympa puisqu'on bénéficie de l'écriture à gauche du " = "
au lieu d'avoir à passer un paramètre.
L'idée de toute façon est d'apporter la simplicité d'écriture d'une donnée
membre toute simple mais en passant par des méthodes.
Bonne continuation,
Mitsuru FURUTA [Microsoft FRANCE]
"ShadowFil" <ShadowFil@discussions.microsoft.com> wrote in message
news:B5D1B972-AFD6-4A0D-A692-67A42DA367BA@microsoft.com...
Bonjour,
Dans l'Application Block "Authorization and Profile", la classe
ExtendedPrincipal possède un attribut :
private StringCollection roles;
et une méthode qui renvoi les roles :
public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une
propriété ?
Avantages et inconvénients ?
Dans ce cas précis, je ne sais pas mais de mainère plus générale, c'est juste un avantage syntaxique. Au niveau de la compilation en IL, les accesseurs get et set d'une propriété génèrent des méthodes. Pour le get en tout cas, c'est donc exactement pareil. Pour le set par contre, c'est plus sympa puisqu'on bénéficie de l'écriture à gauche du " = " au lieu d'avoir à passer un paramètre. L'idée de toute façon est d'apporter la simplicité d'écriture d'une donnée membre toute simple mais en passant par des méthodes.
Bonne continuation,
Mitsuru FURUTA [Microsoft FRANCE]
"ShadowFil" wrote in message news:
Bonjour,
Dans l'Application Block "Authorization and Profile", la classe ExtendedPrincipal possède un attribut : private StringCollection roles; et une méthode qui renvoi les roles : public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une propriété ? Avantages et inconvénients ?
Merci pour votre aide.
Zazar
Bonjour,
Dans l'Application Block "Authorization and Profile", la classe ExtendedPrincipal possède un attribut : private StringCollection roles; et une méthode qui renvoi les roles : public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une propriété ? Avantages et inconvénients ?
Dans le cas général : -> si on doit faire un traitement un peu long pour définir ou obtenir la valeur, on utilisera une méthode plutôt qu'une propriété. (Quand on fait appel à une propriété on s'attend à ce que le temps de traitement soit plutôt faible) -> Si on veut définir des portées d'accés différentes pour définir et pour obtenir la valeur, on est obligé d'utiliser au moins une méthode. (En C# 2.0, cette contrainte n'existera plus). -> Certaines personnes préfèrent utiliser les méthodes quand il s'agit de manipuler des collections et réservent les propriétés aux objets simples. (Il me semble que par défaut, fxcop râle quand on utilise un accesseur pour un tableau mais pas pour une collection quelconque).
Dans votre cas, je pense que la raison est un des 2 derniers points. Si vous avez le source, vous pouvez facilement vérifier si on est dans la situation du 2ième point.
-- Zazar
Bonjour,
Dans l'Application Block "Authorization and Profile", la classe
ExtendedPrincipal possède un attribut :
private StringCollection roles;
et une méthode qui renvoi les roles :
public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une
propriété ?
Avantages et inconvénients ?
Dans le cas général :
-> si on doit faire un traitement un peu long pour définir ou obtenir la
valeur, on utilisera une méthode plutôt qu'une propriété. (Quand on fait
appel à une propriété on s'attend à ce que le temps de traitement soit
plutôt faible)
-> Si on veut définir des portées d'accés différentes pour définir et pour
obtenir la valeur, on est obligé d'utiliser au moins une méthode. (En C#
2.0, cette contrainte n'existera plus).
-> Certaines personnes préfèrent utiliser les méthodes quand il s'agit de
manipuler des collections et réservent les propriétés aux objets simples.
(Il me semble que par défaut, fxcop râle quand on utilise un accesseur pour
un tableau mais pas pour une collection quelconque).
Dans votre cas, je pense que la raison est un des 2 derniers points. Si vous
avez le source, vous pouvez facilement vérifier si on est dans la situation
du 2ième point.
Dans l'Application Block "Authorization and Profile", la classe ExtendedPrincipal possède un attribut : private StringCollection roles; et une méthode qui renvoi les roles : public StringCollection GetRoles();
Quel est l'intérêt de faire une méthode alors que l'on pourrait faire une propriété ? Avantages et inconvénients ?
Dans le cas général : -> si on doit faire un traitement un peu long pour définir ou obtenir la valeur, on utilisera une méthode plutôt qu'une propriété. (Quand on fait appel à une propriété on s'attend à ce que le temps de traitement soit plutôt faible) -> Si on veut définir des portées d'accés différentes pour définir et pour obtenir la valeur, on est obligé d'utiliser au moins une méthode. (En C# 2.0, cette contrainte n'existera plus). -> Certaines personnes préfèrent utiliser les méthodes quand il s'agit de manipuler des collections et réservent les propriétés aux objets simples. (Il me semble que par défaut, fxcop râle quand on utilise un accesseur pour un tableau mais pas pour une collection quelconque).
Dans votre cas, je pense que la raison est un des 2 derniers points. Si vous avez le source, vous pouvez facilement vérifier si on est dans la situation du 2ième point.
