5

I think this question can span multiple languages, but in C# specifically there is a clear distinction between a field (ex: private int a;) and a property (ex: private int b { get; set; }). While there is often good reason to choose one or the other, in many cases they can be used interchangeably and they serve the same purpose and choosing between them is just a matter of convention.

Is there an umbrella term that includes both of these distinct concepts? Something that means "property or field" without having to say "property or field"? The word "variable" could potentially work but that also includes function-scoped variables and I'm not even sure if it technically includes properties.

I want a word I can use when a value should be stored in a class-scoped data construct but it doesn't matter if it's a field or a property.

Improve this question

7 Answers 7

Reset to default
9

No, there is not, only the term "field" is describing correctly what you are after.

I think properties should be seen first and foremost as functions (a replacement for "getter" and "setter" pairs), not a direct replacement for fields. Auto properties (which were not part of the C# language before version 3.0) create an invisible private field under the hood, but it is still a field which stores the value.

The more general, language independent term from OO modeling is member variable. You can use that, if you prefer a more generic term than "field".

Improve this answer
4
  • While the question is tagged C#, there's nothing in the question or title that suggests it is about the C# spec. 'Member' seems to fit quite well here.
    – JimmyJames
    Dec 19, 2018 at 19:14
  • While it may make some sense to just say "field," I have to think that if I talk about storing a value in a field but the field is exposed through a property then it would surely confuse people and they'd point out "Hey that's actually a property and not a field."
    – Kyle Delaney
    Dec 19, 2018 at 19:19
  • @KyleDelaney There should be no confussion, if you have a field exposed through a property then you have a field and you have a property, they are different things and you use different words for them.
    – Stop harming Monica
    Dec 20, 2018 at 11:17
  • @KyleDelaney: I think in good OO design, you have either DTOs (which will typically only contain public fields), or you have non-anemic objects, for which it is probably a good idea to encapsulate every field by a property. If you follow that rule, I think there are less chances to run into confusion. Said that, I am sure I have broken that class design rule in the past several times ;-)
    – Doc Brown
    Dec 22, 2018 at 8:33
3

I've seen "class member" in the old OO books. Maybe if you post a sentence or paragraph from what you are writing it'll be easier to find the most suitable word.

Improve this answer
5
  • 8
    In those languages which have a notion of "class member", that normally includes methods, inner classes, type members, etc. as well.
    – Jörg W Mittag
    Dec 18, 2018 at 20:37
  • agreed. One point of view influenced by more dynamic languages is that what you enumerate are different classes of values (or types) for the class members.
    – gdanov
    Dec 18, 2018 at 20:40
  • "If you store the data in a property or field of your ChildDialog class, you'll be able to access that data in StartAsync."
    – Kyle Delaney
    Dec 18, 2018 at 23:01
  • 1
    I would just go with just 'member' or 'instance member'. 'Class member' implies a static or class level member to me. This is standard terminology. e.g. member variable and member method, 'member' encompasses both.
    – JimmyJames
    Dec 19, 2018 at 19:10
  • As Jörg mentioned, members also include methods
    – Kyle Delaney
    Dec 19, 2018 at 19:14
3

[...] in many case they [properties or fields] can be used interchangeably [...] and choosing between them is just a matter of convention.

It isn't "just a matter of convention". In very few cases fields and properties are interchangeable. The only case I can think of is when a public readonly (or a public const) may be interchangeable with a getter-only property.

Public properties support encapsulation. You can check the new value in the setter and throw exceptions when it isn't acceptable. Public fields don't let you do that.

Is there a programming term that means property or field?

It's called "property or field". Short enough to be used as-is. [Inspired by this comment.]

edit:

... or even shorter. Here's an example sentence in which the term would be used:

"If you store the data in a property or field of your ChildDialog class, you'll be able to access that data in StartAsync." [from O.P.'s comment under another answer]

This works even if you remove the details about the way the data is read from the object, the sentence keeps all of it's meaning and intent. So, one might rewrite: "If you store the data [or state] in a ChildDialog class, you'll be able to access that data in StartAsync." The sentence keeps its meaning an intent whether the data is accessed through a property, or a raw field1, or a getter method GetData(...).

1 Don't do that, please. See above.

Improve this answer
2
  • "Don't do that, please. See above." Can you elaborate?
    – Kyle Delaney
    Dec 20, 2018 at 18:49
  • @Kyle 1st and 2nd paragraphs in the answer.
    – Nick Alexeev
    Dec 20, 2018 at 19:17
1

In python, which had similar distinction between fields and properties (although Python doesn't require any recompilation to switch between the two), the encompassing term is usually "attributes".

Improve this answer
1

While there is often good reason to choose one or the other, in many case they can be used interchangeably and they serve the same purpose and choosing between them is just a matter of convention.

I dispute this assertion. Fields are variables; they are state of an object. Properties are an encapsulation mechanism. Whilst in some simple use cases they can server the same purpose, the power of properties goes way beyond those simple cases.

Properties can be defined within interfaces; they can be defined as one of three states: read-only, read-write and write-only; those read and write states can have different accessibility levels; and they can execute code when used. None of above applies to fields.

Looking for a term to describe fields and properties, but that excludes other members, is to mistakenly assume they are equivalent and thus deserve a special common name. They aren't equivalent and thus they don't deserve a exclusive common name

Improve this answer
1

"Value Member" seems appropriate to me. Fields and properties are both members, but they represent values unlike functions.

Improve this answer
0

Properties don't store data, the hidden backing field behind the property stores data. Properties provide a way to access that field.

Because of the C# syntax, the distinction between a variable and a property fades. But properties and fields are two very different beasts. A property is more like a method then a it is like a variable.

In general, properties are part of the interface of the class and the fields are part of the state of the class. That's the nice thing about the properties, you can change the getters and setters and still have your external representation of your class the same.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.