Question

Je pense avoir utilisé ces termes de manière interchangeable / à tort!

Était-ce utile?

La solution

Iain, il s’agit essentiellement d’une question de terminologie et reste, malgré le "langage agnostique". balise associée à cette question, très liée au langage et à l’environnement.

Pour les discussions de conception, les variables propriété et instance peuvent être utilisées de manière interchangeable, car l’idée est qu’une propriété est une donnée décrivant un objet.

Lorsque vous parlez d'une langue spécifique, ces deux langues peuvent être différentes. Par exemple, en C #, une propriété est en réalité une fonction qui renvoie un objet, tandis qu'une variable d'instance est une variable membre non statique d'une classe.

Autres conseils

Hershi a raison de dire que cela est spécifique à la langue. Mais pour ajouter à la liste des réponses spécifiques à une langue:

En python, une variable d'instance est un attribut d'une instance, (généralement) un élément référencé dans le dictionnaire de l'instance. Ceci est analogue aux membres ou aux variables d'instance en Java, sauf que tout est public.

Les propriétés sont des raccourcis vers les méthodes getter / setter qui ressemblent à une variable d'instance . Ainsi, dans la définition de classe suivante (modifiée à partir du nouveau manifeste d'objets de style de Guido ):

class C(object):

    def __init__(self):
        self.y = 0

    def getx(self):
        if self.y < 0: return 0
        else: return self.y

    def setx(self, x):
        self.y = x

    x = property(getx, setx)

>>> z = C()
>>> z.x = -3
>>> print z.x
0
>>> print z.y
-3
>>> z.x = 5
>>> print z.x
5
>>> print z.y
5

y est une variable d'instance de z , x est une propriété. (En général, lorsqu'une propriété est définie, certaines techniques sont utilisées pour masquer la variable d'instance associée de sorte qu'un autre code ne puisse pas y accéder directement.) L'avantage des propriétés en python est qu'un concepteur n'a pas à s'y déplacer. encapsuler de manière préventive toutes les variables d’instance, car l’encapsulation future en convertissant une variable d’instance en propriété ne devrait pas casser le code existant -programmation technique).

Tout ceci est une très longue réponse pour dire qu’au niveau de la conception, il est bon de parler de propriétés. Le type d’encapsulation que vous devrez peut-être effectuer n’est pas déterminant. Je suppose que ce principe n’est pas agnostique, mais s’applique aux langages autres que python.

exemple de code réalisé en C #

public class ClassName
{
   private string variable;

   public string property
   {
      get{ return variable; }
      set { variable = value; }
   }
}

Dans l’objectif c, une propriété est une variable d’instance pouvant tirer parti d’un opérateur de point surchargé pour appeler ses fonctions de définition et d’obtention. Donc, my.food = " cheeseburger " est en fait interprété comme [my setFood: "cheeseburger"]. C’est un autre cas où la définition n’est certainement pas agnostique à la langue car objective-c définit le mot clé @property.

Peut-être que c'est parce que vous êtes d'abord venu de C ++, n'est-ce pas?! Dans mes jours d'école, j'avais des professeurs qui disaient tout le temps des propriétés ou des attributs de classe. Depuis que j'ai migré vers le monde Java C #, j'ai commencé à entendre parler des membres. Membres de classe, membres d'instance ...

Et puis Propriétés apear! en Java et .NET. Je pense donc qu'il vaut mieux que vous l'appeliez membres. Qu'ils soient membres d'instance (ou comme vous l'appelez variable d'instance) ou membres de classe ....

Salut!

Une propriété peut, et je suppose surtout, renvoyer une variable d'instance, mais elle peut en faire davantage. Vous pouvez insérer une logique dans une propriété, regrouper des valeurs ou mettre à jour d'autres variables d'instance, etc. Je pense toutefois qu'il vaut mieux éviter de le faire. La logique devrait aller dans les méthodes.

En Java, nous avons quelque chose appelé Propriétés JavaBeans , mais il s’agit essentiellement d’une variable d’instance qui suit un certain modèle de nommage pour ses getter et setter.

En plus de ce qui a été dit, dans une langue comme C #, une propriété est essentiellement une fonction get et set. En conséquence, il peut avoir une logique personnalisée qui s'exécute en plus de l'obtention / du paramètre. Une variable d'instance ne peut pas faire cela.

Une propriété est une sorte de donnée associée à un objet. Par exemple, une propriété d'un cercle est son diamètre et une autre est son aire.

Une variable d'instance est une donnée stockée dans un objet. Il ne doit pas nécessairement correspondre directement avec une propriété. Par exemple (heh), un cercle peut stocker son rayon dans une variable d'instance et calculer son diamètre et sa surface en fonction de ce rayon. Les trois sont toujours des propriétés, mais seul le rayon est stocké dans une variable d'instance.

Certaines langues utilisent le concept de "première classe". Propriétés. Cela signifie que, pour une application cliente, la propriété ressemble à une variable d'instance et est utilisée comme telle. C'est-à-dire qu'au lieu d'écrire quelque chose comme circle.getDiameter () , vous écririez circle.diameter et au lieu de circle.setRadius (5) , vous écririez circle.radius = 5 .

Contrairement aux autres réponses données, je pense qu’il existe une distinction utile entre les variables membres et les propriétés qui ne dépendent pas de la langue.

La distinction est plus apparente dans la programmation orientée composant, qui est utile n’importe où, mais plus facile à comprendre dans une interface graphique. Dans ce contexte, j’ai tendance à penser que la configuration en phase de conception d’un composant consiste à manipuler les "propriétés". d'un objet. Par exemple, je choisis les couleurs de premier plan et d'arrière-plan, le style de bordure et la police d'un champ de saisie de texte en définissant ses propriétés. Bien que ces propriétés puissent être modifiées au moment de l'exécution, elles ne le sont généralement pas. Au moment de l'exécution, un ensemble de variables différent, représentant le contenu du champ, est beaucoup plus susceptible d'être lu et écrit. Je pense à cette information comme étant "l'état". du composant.

Pourquoi cette distinction est-elle utile? Lors de la création d'une abstraction pour le câblage de composants, généralement, seul "l'état" les variables doivent être exposées. Pour revenir à l'exemple de champ de texte, vous pouvez déclarer une interface donnant accès au contenu actuel. Mais les " propriétés " qui contrôlent l'apparence du composant ne sont définis que sur une classe d'implémentation concrète.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top