I just realized that I can access shared members from instances of classes (probably this is not correct, but compile and run), and also learn/discover that, I can modify shared members, then create a new instance and access the new value of the shared member.
My question is, what happens to the shared members, when it comes back to the "default" value (class declaration), how dangerous is it do this ? is it totally bad ? is it valid in some cases ?.
If you want to test my point here is the code (console project vb.net) that I used to test shared members, as you can see/compile/run, the shared member "x" of the class "Hello" has default value string "Default", but at runtime it changes it, and after creating a new object of that class, this object has the new value of the shared member.
Module Module1
Public Class hello
Public Shared x As String = "Default"
Public Sub New()
End Sub
End Class
Sub Main()
Console.WriteLine("hello.x=" & hello.x)
Dim obj As New hello()
Console.WriteLine("obj.x=" & obj.x)
obj.x = "Default shared memeber, modified in object"
Console.WriteLine("obj.x=" & obj.x)
hello.x = "Defaul shared member, modified in class"
Console.WriteLine("hello.x=" & hello.x)
Dim obj2 As New hello()
Console.WriteLine("obj2.x=" & obj2.x)
Console.ReadLine()
End Sub
End Module
UPDATE: First at all, thanks to everyone, each answer give feedback, I suppose, by respect I should choose one as "the answer", I don't want to be offensive to anyone, so please don't take it so bad if I didn't choose you answer.
Best Answer
Shared (or static) members don't have an instance. They are not 'part' of an object. Think of shared members or functions as communal. If one piece of code updates a shared member, the next piece of code to access it will see the new value. Shared means 'shared memory'. It's important to understand whose memory it is. Shared memory is shared by all threads within the process space. So, you might be even more surprised if you spun up another thread and tried to access the shared memory space. Your child thread will update the memory of the main thread.
In some languages (e.g., C), you don't need to associate everything with a containing class or module. In other languages (e.g., VB) you provide a context for your member in the form of a class, but that's really only so you can a) find it, and b) hide it if you want to.
Private shared members will be visible only to members of a class, but they're still shared. With shared functions, each caller gets a copy of any parameters passed to the function, but that's it. If the function uses any shared members, they are potential trouble spots for two reasons. First, later on in your code, you might forget who/what last updated the shared member so it could have an unexpected value. Second, if your program is multithreaded, you can create resource contention which are very difficult to diagnose.
Shared members and functions are absolutely valid in many cases. You should consider what you're trying to do, whether there might be write-contention for a given resource, and whether there are performance considerations (e.g., caching). If you're a beginner programmer, I'd suggest you fully understand shared members/functions before you get into the habit of using them. A good place to use them is with functions that don't have side-effects (i.e., that don't change program state by setting other members). Then you might use them for things like caches (if you really need that) among other things. Just don't abuse them.