.NET - Quand devrais-je utiliser une propriété ou une fonction variable + accesseur?

Question

Existe-t-il une situation où je devrais faire ce qui suit dans .NET au lieu d'utiliser une propriété avec capacité de lecture/écriture?

private S as string 

public function GetS() as string 
    return S 
end function 

public sub SetS(byval NewS as string) 
    S = NewS 
end function 

Est-ce que les propriétés fournissent simplement un moyen plus efficace de faire la même chose?

Les propriétés seront-elles plus lentes que les fonctions d'accès ci-dessus dans une application haute performance? Les propriétés, en interne, ne sont rien d'autre qu'une paire de méthodes.

Answer 1

Ils évaluent fondamentalement à une méthode get et set accessor.

Vous devez utiliser des propriétés, à moins que la propriété ne provoque des effets secondaires inattendus et potentiellement longs, ou qu'il existe d'autres bonnes raisons d'utiliser une méthode. Pour des détails, je suggère de lire le Property Usage Guidelines on MSDN. En particulier, utilisez une méthode lorsque:

• L'opération est une conversion, telle que Object.ToString.
• L'opération est assez coûteuse pour que vous souhaitiez communiquer à l'utilisateur qu'il doit envisager de mettre en cache le résultat.
• L'obtention d'une valeur de propriété à l'aide de l'accesseur get aurait un effet secondaire observable.
• L'appel deux fois de suite du membre produit des résultats différents.
• L'ordre d'exécution est important. Notez que les propriétés d'un type doivent pouvoir être définies et récupérées dans n'importe quel ordre.
• Le membre est statique mais renvoie une valeur qui peut être modifiée.
• Le membre renvoie un tableau.

Sinon, j'utiliserais une propriété. Brad Abram's blogged some other details, y compris les bonnes raisons pour lesquelles certaines fonctions de l'API utilisent des méthodes (principalement parce qu'elles peuvent provoquer une communication entre ordinateurs, qui tomberait dans la catégorie "effet secondaire").

Answer 2

Les propriétés sont en réalité du sucre syntactique pour les méthodes appelées get_MyProperty et set_MyProperty, donc il n'y a pas de différence de performance.

Answer 3

Oui, au moins dans mon expérience, j'essaie d'éviter les propriétés et d'utiliser la fonction et les routines en place. Voici mes raisons pour lesquelles:

1. Impossible d'utiliser les propriétés avec des délégués. Je crois que vous pouvez en C# mais sur
2. Les propriétés sont trompeuses, elles ressemblent à des membres, mais se comportent comme des fonctions. Ainsi, alors que vous pourriez penser que vous êtes en train de regarder une valeur de membre, vous pourriez en fait initialiser le système entier à nouveau parce que le développeur de l'implémentation a abusé de l'instanciation paresseuse.

3. Moins de code, bien que ce ne soit pas une quantité ÉNORME, la définition de propriétés dans VB nécessite au moins 2 lignes de code supplémentaires par get ou set. Le surcoût est le double des lignes du code réel pour une seule opération d'affectation ou de retour. Bien que cela rende le code de lecture beaucoup plus difficile, VB est déjà un langage obsessionnel.

   Private ReadOnly Property Foo As String 
       Get 
        Return Bar 
       End Get 
   End Property 
   

   vs

   Private Function Foo As String 
       Return Bar 
   End Function 
   

4. Les propriétés sont moins souples que vous devez retourner ce que la même valeur que vous obtenez. En d'autres termes, vous ne pouvez pas définir la valeur à l'aide d'un String et d'utiliser un Integer ou un paramètre de surcharge avec un String ou un Integer.

Maintenant, pour être juste les raisons que j'utiliser les propriétés est d'obtenir la syntaxe = pour le réglage qui cela ne vaut pas lorsque vous avez une propriété en lecture seule. Les propriétés peuvent également être définies dans l'éditeur VS dans la boîte de dialogue des propriétés.

Answer 4

Une autre décision concernant l'utilisation de propriétés ou de fonctions est l'instanciation de l'objet parent. VB a cette syntaxe merveilleusement pratique, par ex.

Dim MyStudent as Student With {.Name = "Bobby", .Age = 10} 

Seules les propriétés sont disponibles dans la section Avec.

Je maintiens une application qui a beaucoup d'objets persistants dans une base de données, qui a beaucoup de relations entre les objets. par exemple. un étudiant a un enseignant, et l'enseignant est peristed dans la DB.

J'utilise généralement une propriété WriteOnly pour définir l'enseignant, car il s'agit d'une opération légère, mais compte tenu de l'accès DB potentiellement coûteux pour récupérer l'enseignant, j'utilise une fonction à extraire. En d'autres termes:

Public Writeonly Property Teacher() as Teacher 
Public Function GetTeacher() as Teacher 

Cela me permet instancier un étudiant sous la forme With {.Teacher = SomeTeacherObject} mais GetTeacher encourage la mise en cache de l'objet de l'enseignant dans le code utilisateur et pas seulement l'utiliser comme propriété qui peut ou ne peut pas donner lieu à accès multiple DB appels.

Si quelqu'un a des commentaires sur cette approche, j'aimerais les entendre.

Answer 5

Avec les conceptions à niveaux multiples, dans mon BO, je stocke les valeurs de propriété avec une valeur non définie, puis la règle lors de la première utilisation. De cette façon, je ne m'inquiète jamais si j'analyse les propriétés dans le bon ordre, puisque je les charge paresseusement.