What's the difference between Module and Class ? It's mentioned that Module is a file for storing groups of functions, can we store subroutines too ? Why if we want to access a function in a class, we should use keyword Public Shared Function while in a module we just use keyword Public Function ?
A module basically is a class, but one that you cannot create an instance of. In C#, there's no such thing as a module; there are just classes.
C# has a 'static' keyword that you can apply to class members to indicate that they are accessed via the class itself rather than instances of that class. VB has a 'Shared' keyword that can be used in the same way.
In C#, you can also apply the 'static' keyword to classes. If a class is declared static then every member of that class must be declared static as well and you are not allowed to create an instance of that class in code even if you wanted to. In VB, you cannot define a Shared class. If you want a type that you cannot create an instance of and has all Shared members then you define a module.
The result of compiling a C# static class and a VB module is exactly the same, so modules are essentially Shared classes. Microsoft chose to use the module syntax for compatibility with VB6 and earlier. A VB6 module can be copied into VB.NET and will work with often very little and sometimes no changes at all. It's not possible to have a member in a module that isn't Shared so they omitted the 'Shared' keyword on members for convenience and, again, compatibility with existing code.
P.S. The vast majority of the .NET Framework was written in C#. An example of a static class in the .NET Framework is the System.IO.File class. It does not appear as a module in VB because it was not created as a VB module but all its members (other than those it inherits from Object) are Shared and you can't create an instance.
As I said, a module basically is a class. The main difference is that a module's members are all inherently Shared. If you need to create a type that would have all Shared members then you should create a module, otherwise create a class. Be mindful of the fact that there are thousands of classes in the .NET Framework and only a small number of modules or static classes.
As I said, a module basically is a class. The main difference is that a module's members are all inherently Shared. If you need to create a type that would have all Shared members then you should create a module, otherwise create a class. Be mindful of the fact that there are thousands of classes in the .NET Framework and only a small number of modules or static classes.
By inherently shared do you mean Public vs Private?
I'm trying to fathom why a module is even needed. I watched this video VB.NET Tutorial 55 - Modules (Visual Basic 2008/2010) - YouTube and I fail to grasp why the module used by the command button made anything more efficient, save the fact that perhaps you could use that module over with a pointer should the need arise. But can't you just as easily to the same thing with a Sub in a class?
By inherently shared do you mean Public vs Private?
I'm trying to fathom why a module is even needed. I watched this video VB.NET Tutorial 55 - Modules (Visual Basic 2008/2010) - YouTube and I fail to grasp why the module used by the command button made anything more efficient, save the fact that perhaps you could use that module over with a pointer should the need arise. But can't you just as easily to the same thing with a Sub in a class?
No, I don't mean Public vs Private. The two are unrelated. Public means that a member can be accessed from outside the type and Private means that a member can only be accessed from inside the type. Both modules and classes can have Public and/or Private members.
A Shared member is one that is accessed via the type itself, as opposed to via an instance of the type. The most obvious example is the MessageBox.Show method. You don't do this, do you:
Dim mb As New MessageBox
mb.Show("Hello World")
No, you do this:
MessageBox.Show("Hello World")
You call Show on the MessageBox class itself, not an instance of the class. That's because it is a Shared method.
Consider also the System.IO.File class. You never actually create an instance of that class. You call members like Copy and Delete on the File class itself. Again, because those members are Shared.
There's definitely a grey area where it's not clear whether a class or module is a better option. Sometimes it's obvious that a class with instance members is required but other times you could use a class with instance members, a singleton class or a module. It becomes easier to make the decision as you get more experience but that just makes the grey area smaller, not go away altogether. If you find that you want to group some functionality that logically belongs together but doesn't logically belong to an object, there's a good chance that a module is the appropriate choice.
No, I don't mean Public vs Private. The two are unrelated. Public means that a member can be accessed from outside the type and Private means that a member can only be accessed from inside the type. Both modules and classes can have Public and/or Private members.
A Shared member is one that is accessed via the type itself, as opposed to via an instance of the type. The most obvious example is the MessageBox.Show method. You don't do this, do you:
Dim mb As New MessageBox
mb.Show("Hello World")
No, you do this:
MessageBox.Show("Hello World")
You call Show on the MessageBox class itself, not an instance of the class. That's because it is a Shared method.
Consider also the System.IO.File class. You never actually create an instance of that class. You call members like Copy and Delete on the File class itself. Again, because those members are Shared.
There's definitely a grey area where it's not clear whether a class or module is a better option. Sometimes it's obvious that a class with instance members is required but other times you could use a class with instance members, a singleton class or a module. It becomes easier to make the decision as you get more experience but that just makes the grey area smaller, not go away altogether. If you find that you want to group some functionality that logically belongs together but doesn't logically belong to an object, there's a good chance that a module is the appropriate choice.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
range:
