Why shouldn't an object reference have access to a static member in C#

Question

Context of my question:

1. I am reading C#.
2. Trying to understand Static keyword.
3. I understand that when Static is applied to a member of a class, it can only be modified by the class and not the class object references.

I will take an example here.

public class BluePrint
{
 public static string BluePrintCreatorName;
}

If I need to know the BluePrintCreator's Name, I can call

BluePrint.BluePrintCreatorName;

But if a house that is created from the blueprint wants to know the BluePrintCreator's Name, it does not have access.

BluePrint NewHouse = new BluePrint();
NewHouse.BluePrintCreatorName; //This is not accessible

Compiler error says:

Member 'AccessModifier.BluePrint.BluePrintCreatorName' cannot be accessed 
with an instance reference; qualify it with a type name instead 

I understand this is the way it works. But I want to know the basic concept to why Static keyword was required at all?

What will go wrong if a class object reference would have access to the static member?

• thorsten müller: Your example is not very good, since the area of a house is obviously relevant to the instance, nor shared by all instances (each house will have a different area). A better, though simple example would be just a counter variable for instances. Each time you create an instance its constructor would increase this static counter, the destructor decrease it.
• blogbydev: I see this is not the case in java. example here : ideone.com/4FslaY . If someone could point me to what was the reason behind not allowing this in C#. that would be my answer.
• Stack Exchange Broke The Law: You'd just write BluePrint.BluePrintCreatorName instead of NewHouse.BluePrintCreatorName. Simple fix.

Answer 1

Nothing go wrong for accessing a static member from an instance, in fact this is perfectly possible in other languages like java, your example code compiles and runs ok if its in java.

It's a check the compiler designers have introduced because they thought that this will help programmers to write clear code with this language. On this way only looking at the code you can always know if you are accessing a static or an instance member, in languages where this access is allow (like java) sometimes its a little confusing when someone decides to access a static member throughout an instance variable, in fact normally when you see this access in java code its more a mistake than a programmer really using this "language feature".

In my opinion limiting this access its a good decision in C# to avoid some mistakes and bad interpretations.

Although it's legal in Java to refer static members that way, it's recommended against in Code Conventions (10.2 Referring to Class Variables and Methods):

"Avoid using an object to access a class (static) variable or method. Use a class name instead..."

• gnat: FWIW although in Java it's legal to refer static members that way, it's recommended against in Code Conventions (10.2 Referring to Class Variables and Methods): "Avoid using an object to access a class (static) variable or method. Use a class name instead..." (consider editing this into your answer)
• Tim Schmelter: @gnat: good point, added it to the answer
• Deduplicator: You might want to compare with a lanuage like C++, which allows free functions and thus the programmer has no motivation to stuff a static function neither accepting nor creating a thread into a thread-class designed for creating and managing additional threads.

Answer 2

Consider the following (legal) Java code:

Thread workerThread = new MyWorkerThread();
workerThread.start();
workerThread.sleep(5000);

At first glance, it looks like the last line is requesting that workerThread sleep for five seconds. However, the Thread.sleep method is actually static, and makes the current thread sleep.

In C#, requiring static functions to be called through the class instead of an instance helps prevent writing misleading code like this.

• greenoldman: While appealing example at first glance, it is actually badly designed class. Current thread should not be accessed directly by static methods, but indirectly by static member (field or getter) and calling regular methods using it, e.g. workerThread.current.sleep(5000) says a lot more.
• Deduplicator: @greenoldman: Though of course, making any thread but the current one sleep is error-prone. The problem is putting the methods for manipulating the current thread in a class representing any thread, even as static members.
• greenoldman: @Deduplicator, you didn't hear me -- "The problem is putting the methods for manipulating the current thread". That's exactly wrong design, there should be no such thing as methods for current thread. There should be current thread object (instance) that's all.

Answer 3

What will go wrong if a class object reference would have access to the static member?

It is not the reference that matters, a reference is for you to know what instances your dealing with. static members work like this; they are part of a class, but they are not part of an instance derived from that class.

I understand this is the way it works. But I want to know the basic concept to why Static keyword was required at all?

Before OOP was mature, there were no runtime environments that allowed the initialization of individual objects. Programs were basically a collection of subroutines which would call each other cohesively. You can think of this as "static" to get the right idea. Even when OOP became mature, the idea of independent classes still appealed because they are accessible unconditionally. On a runtime level static classes are like instances too, but thats not how they appeal from the language. Now there is also such thing as static members, but having those in conjunction with a non-static class is unusual because it could cause unexpected behavior with asynchronous operations, note that this doesn't apply for static readonly members.