Propriétés vs méthodes

Question

Question rapide: Quand décidez-vous d'utiliser des propriétés (en C #) et quand décidez-vous d'utiliser des méthodes?

Nous sommes occupés par ce débat et nous avons trouvé des domaines dans lesquels il est discutable de savoir si nous devrions utiliser une propriété ou une méthode. Voici un exemple:

public void SetLabel(string text)
{
    Label.Text = text;
}

Dans l'exemple, Label est un contrôle situé sur une page ASPX. Existe-t-il un principe qui puisse régir la décision (dans ce cas) d’en faire une méthode ou une propriété.

J'accepterai la réponse la plus générale et la plus complète, mais cela concerne également l'exemple que j'ai donné.

Answer 1

Extrait du Choix entre des propriétés et des méthodes

  

En général, les méthodes représentent des actions et les propriétés représentent des données. Les propriétés sont destinées à être utilisées comme des champs, ce qui signifie qu'elles ne doivent pas être complexes du point de vue calcul, ni produire d'effets secondaires. Lorsque cela n’enfreint pas les directives suivantes, envisagez d’utiliser une propriété plutôt qu’une méthode, car les développeurs moins expérimentés trouvent les propriétés plus faciles à utiliser.

Answer 2

Oui, si tout ce que vous faites est obtenir et définir, utilisez une propriété.

Si vous faites quelque chose de complexe pouvant affecter plusieurs membres de données, une méthode est plus appropriée. Ou si votre getter prend des paramètres ou si votre setter prend plus d’un paramètre de valeur.

Au milieu se trouve une zone grise où la ligne peut être un peu floue. Il n'y a pas de règle absolue et différentes personnes seront parfois en désaccord sur le point de savoir si quelque chose doit être une propriété ou une méthode. L'important est simplement d'être (relativement) cohérent avec la façon dont vous le faites (ou comment votre équipe le fait).

Ils sont en grande partie interchangeables, mais une propriété indique à l'utilisateur que la mise en œuvre est relativement "simple". Oh, et la syntaxe est un peu plus propre.

De manière générale, ma philosophie est que si vous commencez à écrire un nom de méthode qui commence par get ou set et prend zéro ou un paramètre (respectivement), il constitue un candidat idéal pour une propriété.

Answer 3

Si vous définissez une propriété réelle de votre objet, vous utilisez une propriété.

Si vous effectuez une tâche / fonctionnalité, vous utilisez une méthode.

Dans votre exemple, il s'agit d'une propriété définie en cours de création.

Si, toutefois, votre fonctionnalité était destinée à AppendToLabel, vous utiliseriez une méthode.

Answer 4

Les propriétés sont un moyen d’injecter ou de récupérer des données d’un objet. Ils créent une abstraction sur les variables ou les données d'une classe. Ils sont analogues aux getters et setters de Java.

Les méthodes encapsulent une opération.

En général, j'utilise des propriétés pour exposer des bits de données uniques ou de petits calculs sur une classe, telle que la taxe de vente. Qui est dérivé du nombre d'articles et de leur coût dans un panier.

J'utilise des méthodes pour créer une opération, par exemple pour récupérer des données de la base de données. Toute opération comportant des pièces mobiles est candidate à une méthode.

Dans votre exemple de code, je l'envelopperais dans une propriété si je dois y accéder en dehors de la classe qui le contient:

public Label Title 
{
   get{ return titleLabel;}
   set{ titleLabel = value;}
}

Définition du texte:

Title.Text = "Properties vs Methods";

Si je ne définissais que la propriété Text du libellé, voici comment je procéderais:

public string Title 
{
   get{ return titleLabel.Text;}
   set{ titleLabel.Text = value;}
}

Définition du texte:

Title = "Properties vs Methods";

Answer 5

En cherchant dans MSDN, j'ai trouvé une référence sur Propriétés vs Méthodes qui fournit d'excellentes indications pour la création de méthodes:

  

  
• L'opération est une conversion, telle que Object.ToString .
  
• L’opération est suffisamment chère pour que vous souhaitiez communiquer avec le   utilisateur qu'ils devraient 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 observable.   effet secondaire.
  
• L'appel du membre deux fois de suite donne des résultats différents.
  
• L'ordre d'exécution est important. Notez que les propriétés d'un type doivent   pouvoir être réglé et récupéré dans tout   ordre.
  
• Le membre est statique mais renvoie une valeur qui peut être modifiée.
  
• Le membre retourne un tableau. Les propriétés qui retournent des tableaux peuvent être   très trompeur. Habituellement c'est   nécessaire de renvoyer une copie du   tableau interne de sorte que l'utilisateur ne peut pas   changer d'état interne. Ceci, couplé   avec le fait qu'un utilisateur peut facilement   supposons qu'il s'agisse d'une propriété indexée,   conduit à un code inefficace.
  

Answer 6

Symantiquement, les propriétés sont des attributs de vos objets. Les méthodes sont des comportements de votre objet.

L'étiquette est un attribut et il est plus logique d'en faire une propriété.

En termes de programmation orientée objet, vous devez avoir une idée claire de ce qui fait partie du comportement et de ce qui n’est qu’un attribut.

Voiture {couleur, modèle, marque}

Une voiture a des attributs de couleur, de modèle et de marque. Par conséquent, il n'est pas logique de définir une méthode SetColor ou SetModel car, de manière symétrique, nous ne demandons pas à Car de définir sa propre couleur.

Donc, si vous mappez le cas propriété / méthode sur l'objet de la vie réelle ou si vous le regardez d'un point de vue symantique, votre confusion disparaîtra vraiment.

Answer 7

Il suffit de regarder le nom même de "Propriété". Qu'est-ce que ça veut dire? Le dictionnaire le définit de nombreuses manières, mais dans ce cas, "un attribut essentiel ou distinctif ou la qualité d'une chose" correspond le mieux.

Pensez au but de l'action. En fait, modifiez-vous ou récupérez-vous "un attribut essentiel ou distinctif"? Dans votre exemple, vous utilisez une fonction pour définir une propriété d'une zone de texte. Cela semble un peu bête, n'est-ce pas?

Les propriétés sont vraiment des fonctions. Ils compilent tous jusqu'à getXXX () et setXXX (). Il les cache simplement dans le sucre syntaxique, mais c'est le sucre qui donne un sens sémantique au processus.

Pensez aux propriétés telles que les attributs. Une voiture a beaucoup d'attributs. Couleur, MPG, Modèle, etc. Toutes les propriétés ne sont pas configurables, certaines sont calculables.

Pendant ce temps, une méthode est une action. GetColor devrait être une propriété. GetFile () devrait être une fonction. Une autre règle est que, si cela ne change pas l'état de l'objet, il devrait alors s'agir d'une fonction. Par exemple, CalculatePiToNthDigit (n) devrait être une fonction, car elle ne modifie pas réellement l'état de l'objet Math auquel il est attaché.

C’est peut-être un peu difficile, mais il s’agit vraiment de décider quels sont vos objets et ce qu’ils représentent. Si vous ne pouvez pas déterminer s’il s’agit d’une propriété ou d’une fonction, peut-être que cela importe peu.

Answer 8

Je préfère utiliser les propriétés pour les méthodes d'ajout / définition avec le paramètre 1 . Si les paramètres sont plus nombreux, utilisez des méthodes.

Answer 9

Les propriétés ne doivent être que simples et obtenir un seul support. Rien de plus et il devrait vraiment être déplacé vers une méthode. Le code complexe doit toujours figurer dans les méthodes.

Answer 10

J’utilise uniquement les propriétés pour l’accès aux variables, c’est-à-dire obtenir et définir des variables individuelles ou obtenir et définir des données dans des contrôles. Dès que des manipulations de données sont nécessaires / nécessaires, j’utilise des méthodes.

Answer 11

Un autre avantage important des propriétés est que la valeur de la propriété peut être vue dans Visual Studio lors du débogage.

Answer 12

Les propriétés sont vraiment intéressantes car elles sont accessibles dans le concepteur visuel de visual studio, à condition qu’elles y aient accès.

Ils sont utilisés si vous vous contentez de définir et d’obtenir une validation qui ne permet pas d’accéder à une quantité importante de code. Soyez prudent car la création d'objets complexes lors de la validation n'est pas simple.

Toutes les autres méthodes sont recommandées.

Ce n’est pas seulement une question de sémantique. L'utilisation de propriétés inappropriées provoque des phénomènes étranges dans Visual Studio Visual Designer.

Par exemple, je recevais une valeur de configuration dans une propriété d'une classe. La classe de configuration ouvre en fait un fichier et exécute une requête SQL pour obtenir la valeur de cette configuration. Cela posait des problèmes dans mon application, où le fichier de configuration était ouvert et verrouillé par Visual Studio lui-même plutôt que par mon application, car il lisait et écrivait la valeur de configuration (via la méthode setter). Pour résoudre ce problème, je devais simplement le changer en méthode.

Answer 13

En ce qui concerne la conception, les propriétés représentent des données ou des attributs d'objet classe, tandis que les méthodes sont des actions ou des comportements d'objet classe.

En .Net, l'univers de l'utilisation des propriétés a d'autres implications:

• Les propriétés sont utilisées dans la liaison de données, contrairement aux méthodes get_ / set_.
  
• Les propriétés utilisateur de la sérialisation XML en tant que mécanisme naturel de sérilisation.
  
• Les propriétés sont accessibles via PropertyGrid contrôle et interne ICustomTypeDescriptor , qui peuvent être utilisés efficacement si vous écrivez une bibliothèque personnalisée.
  
• Les propriétés sont contrôlées par Attributs , on peut l’utiliser judicieusement pour concevoir des logiciels orientés aspect.

Idées fausses (IMHO) sur l'utilisation des propriétés:

• Utilisé pour exposer de petits calculs: Le bloc de lecture de ControlDesigner.SelectionRules comporte 72 lignes!
  
• Utilisé pour exposer les structures de données internes: même si une propriété n'est pas mappée sur un membre de données interne, vous pouvez l'utiliser comme propriété si c'est un attribut de votre classe. Viceversa, même si c'est un attribut de vos propriétés de classe, n'est pas conseillé, pour renvoyer un tableau comme des membres de données (à la place, les méthodes sont utilisées pour renvoyer une copie complète des membres.)

Dans l'exemple ci-dessous, il aurait pu être écrit, avec un sens plus commercial tel que:

public String Title
{
    set { Label.Text = text; }
}

Answer 14

Voici un bon ensemble de instructions sur l'utilisation des propriétés par rapport aux méthodes de Bill Wagner

• Utilisez une propriété lorsque toutes ces conditions sont remplies: Les accesseurs doivent être simples et donc peu susceptibles de générer des exceptions. Notez que cela n'implique aucun accès réseau (ou base de données). L’un ou l’autre pourrait échouer et provoquerait donc une exception.
• Ils ne devraient pas avoir de dépendance les uns sur les autres. Notez que cela inclurait la définition d’une propriété et l’affectation de celle-ci à une autre. (Par exemple, la définition de la propriété FirstName affectera une propriété FullName en lecture seule qui compose les propriétés prénom + nom implique une telle dépendance.)
• Ils devraient pouvoir être réglés dans n'importe quel ordre
• Le getter n'a pas d'effet secondaire observable. Notez que cette directive n'empêche pas certaines formes d'évaluation paresseuse dans une propriété.
• La méthode doit toujours être renvoyée immédiatement. (Notez que cela empêche une propriété qui effectue un appel d'accès à la base de données, un appel de service Web ou une autre opération similaire).
• Utilisez une méthode si le membre retourne un tableau.
• Les appels répétés au getter (sans code intermédiaire) doivent renvoyer la même valeur.

• Les appels répétés au correspondant (avec la même valeur) ne doivent donner aucune différence par rapport à un seul appel.

• Le get ne doit pas renvoyer de référence aux structures de données internes (voir le point 23). Une méthode peut renvoyer une copie complète et éviter ce problème.

* Tiré de ma réponse à une question dupliquée.

Answer 15

C'est simple.

1: lorsque vous souhaitez que vos données soient validées avant d’être stockées dans le champ. Ainsi, de cette manière, la propriété fournit une encapsulation pour vos champs. Parce que si vous laissez vos champs, l'utilisateur final public peut attribuer toute valeur qui peut ou non être valide selon vos exigences professionnelles, par exemple si votre âge doit être supérieur à 18 ans. Donc, avant que la valeur soit stockée dans le champ correspondant, nous devons en vérifier la validité. De cette manière, les propriétés représentent des données.

2: Utilisez la méthode lorsque vous souhaitez effectuer une action, par exemple si vous fournissez des données en tant que paramètre et que votre méthode effectue un traitement sur la base des valeurs fournies et renvoie la valeur traitée en sortie. Ou vous voulez changer la valeur d'un champ par ce calcul. "De cette façon, la méthode représente une action".

Answer 16

Je viens de Java et j’ai utilisé la méthode .. set .. pendant un certain temps.

Lorsque j'écris du code, je ne me le demande pas: "accéder à ces données est simple ou nécessite un processus lourd?" parce que les choses peuvent changer (aujourd'hui, cette propriété est simple, demain, un processus lourd ou fastidieux peut être nécessaire).

Aujourd'hui, j’ai une méthode SetAge (int age) demain, j’aurai aussi une méthode SetAge (date de naissance) qui calcule l’âge en utilisant la date de naissance.

J'ai été très déçu que la propriété de transformation du compilateur dans get et set, mais ne considère pas mes méthodes Get ... et Set .. comme identiques.