A: 

They can be both according to meaning. Most of DateTime's properties are calculated fields. DateTime is represented by a long and all its properties are calculated based on that value.

Yuriy Faktorovich
Thanks, but DateTime was used to illustrate the meaning of my question, I'm looking for other and possibly better self-explaining examples
Abel
My point was that some properties have to do with an instance, some are with a type. DateTime.Today is a type example, and myDateTime.Day is an instance property.
Yuriy Faktorovich
+2  A: 

Whether you decide to make a property static or not should be determined by the semantics of that particular property, not whether it's backed by a field.

LukeH
I understand that difference, sorry if I phrased my q. unclear, see my recent edit. I'm looking for real-world, clear and self-explaining examples.
Abel
+5  A: 

Whether a property is static or instance depends on it's purpose and meaning.

The reason that DateTime.Today is static is because it is actually returning an instance of DateTime - it would be awkward to first have to create a DateTime to then call an instance method (or instance property) to get the current date.

You should consider making a property static if:

  • It does not represent the state of a particular object instance.
  • It is not get written to - or if written to is designed to be thread-safe. (You have to define what thread safe means, of course).
  • It is a factory property that is used to return an instance of an object (singleton accessor properties come to mind).
  • You don't expect to need an instance property with the same name (C# does not allow duplicate named properties that only differ by whether they are instance vs. static).

Otherwise, the property probably needs to be an instance property - or perhaps a method.

Some interesting examples of static properties in .NET itself include:

  • Singleton accessor properties.
  • DependencyProperty definitions in WPF
  • Globally accessible readonly state, like the Culture instances for formatting strings.

EDIT: In thinking about places where instance v. static properties are used in .NET, the Thread class comes to mind as an example of a class that is confusing in its choice of when to use which.

For example, the CurrentPrincipal property is a static property while CurrentCulture property is an instance property instead. It's unclear if there is any benefit in this organization - it seems (to me) that all of the static properties of Thread could have been made instance properties (except CurrentThread) without losing any expressive power, but adding consistency and clarity to the public interface.

LBushkin
(strange, my comment was not submitted). These are excellent points, can you elaborate with a few concrete examples, esp. where instance props are used but statics would've been fine (language-wise) as with `Array.IsReadOnly` (which does not return a field, but a constant and could be static, however I don't consider that a "clear" example).
Abel
I'll try to think of some clear examples.
LBushkin
I like the vagueness of `Thread` as a good example. It wasn't really what I was after (I was looking for *clear* examples of either), but the opposite, an *unclear* example does help in the discussion in the classroom. Thanks.
Abel