So I've been programming in C# for the last 6 years or so and now I'm getting my feet wet with VB.net.
The code base I'm working with uses some modules. To me the module looks a lot like a singleton. Only one exists; it can be called anywhere inside the namespace.
Is there something I'm missing here? Does VB not support the normal way a singleton is structured (private constructor/public instance field)?
Modules are not a singleton. It is much more akin to a static class in C#. If you decompile the code you will see they have a very similar structure (modules have an extra attribute).
The major differences between a C# static class and a VB.Net module are ...
Don't have to add Static / Shared qualifiers to methods in a module. They are Shared by default and you cannot change this
If a Module is in an Imported namespace, all of its methods are available without qualification.
Static classes in C# can be generic, modules cannot (although they can have generic members)
If I'm not mistaken, a VB module is the same thing as a static class.
Related
I am creating a .dll for a CAD tool I use.
After creating a new project (class library) , I got a "public class-end class" block.
I wrote my main method inside that block. When I run the dll in my CAD tool, its giving me main entry point missing error.
So i come back and change the "public class-end class" ---> "Public Module-end Module".
Now its able to find the main method.
Why is this so? Ive read on these forums that we should not be using modules as much.
If I were to not use modules so much, how I am supposed to make it work without the module block?
VB.Net doesn't have static classes like C# has. Static classes allow you to create static methods such that
class foo
{
void bar() {}
}
Accessed in VB.Net like this
foo.bar()
If you want to create the same functionality with VB.Net you have two options, which are either using a Module
Module foo1
Sub bar()
End Sub
End Module
Class foo2
Shared Sub bar()
End Sub
End Class
However the difference is how Module and Class are scoped. Modules are globally scoped so you can call the module method outside of the originating namespace without qualifying it with the Module name, but to call the static method you need to qualify it with the class name, and even import the namespace in the case of a class with static method
bar()
foo2.bar()
But what Modules are certainly good for is Extension Methods, and the global scope actually helps here if you want to extend a class across your project
Module Extensions
<Extension>
Sub bar(value As String)
End Sub
End Module
Dim s = "my string"
s.bar()
In your case, it's expecting a C# style static class with method, and since VB.Net doesn't have static classes, a Module or class with static method both satisfy that.
Modules come from legacy versions of Visual Basic and sort of act as the "OG" of Visual Basic code files. When Visual Basic 6 and earlier was around, Visual Basic was sort of quasi object oriented and while classes existed, it made more sense to use modules in lieu of static classes. Then when Visual Basic .NET was introduced, Microsoft made a real effort to make the programming language a true object oriented programming language.
People likely tell you to use classes over modules because modules are holdovers from the days prior to Visual Basic being a pure object oriented language. Starting from 2005 on forward, anything you could do in a module could basically be done as a static (aka shared) only class with the exception of extension methods. So by using classes over modules, you're taking a more .NET oriented approach rather than a Visual Basic first approach.
With regards to your specific problem, the issue is that your CAD tool is looking for an entry method, but cannot find one. The simple solution is to add a shared method:
Public Class MyClass
Public Shared Sub Main()
' ...
End Sub
End Class
I am hobby programmar.Now, am in the middle of making a class library in vb.net. I am making some necessary win32 API functions inside a class library and use it in my hobby projects for ease of use.
I have a main class and few modules in this project. For easiness, i made each module for each section. For example a window module for window related api declarations and variables and structure. The main class contains only all the wrapper functions. So i am declared the variables and structures and api declarations as public so that i can access them from main class. After i build this class library, i just tested it. But there is a problem. All public vars and structures and declarations are available to access there in my test project. I need to hide those declarations and structures and special vars. They are for internal use. But how to make them hide ? When i declared them as private, i can't access them from my wrapper function in Mainclass. What to do
Some of my co-workers make extensive use of the VB.net concept of Modules. Unfortunately, I just don't 'get it'. I see no benefit in using modules over shared classes. Am I missing something? When would it be preferable to use a module? Or am I (as I do quite often in this language) 'just not getting it'?
In VB.net a module is a shared class. When they are compiled they are given a private constructor and methods set to shared.
There are some times when you are forced to use modules by the compiler (in the same way static classes are in C#) such as for extension methods which can not be created in side a VB.Net class.
By using modules for your helper methods you will make it easier to convert them over to extension methods later and restrict others from adding any instance methods or constructors.
That said they are a hang over from VB6 that did not support full OO programming and beyond standalone helper methods they would not widely be used.
A module is essentially the same as a shared class. The major difference is that in a module, there's no need for all the extra "shared"s, cause everything's implicitly shared. If you have no instance data and are just using the class as a kind of namespace for functions, then it's a better idea (IMO) to use a module instead and make that clear.
I am not a program designer by any means but I would really like to start getting a better grasp of how to do it and a better understanding of the .NET languages in general (VB, C#). I was reading a book by Wrox - Professional Visual Basic 2008. In it I believed it mentioned that Modules are slowly going out of existence. I can see why most coding would go into a class object but I would assume modules would always be necessary to at least keep the code clean.
Could anybody clarify this up for me? Also, I have been searching for a good source on software design but I can't seem to find any recent books published. I might be searching in the wrong places but I would really like to get my hands on one.
Thank you.
While in general they don't quite fit with OOP, they are still used and are required in some cases.
In VB.Net, if you wish to write extension methods, you are going to have to use a Module - The compiler will only allow Extension Methods to be defined in one.
You could of course get round not using Modules - an Non Inheritable Class with a private constructor and nothing but Shared Methods will achieved the same thing as a Module.
Like everything in programming (and many other things), they have their uses, and as long as they are not miss-used there is no problem with them. Right tool for the job!
The Module keyword in VB.NET primarily exists for compatibility with VB6 and earlier. Back then, most VB code was procedural with free-standing non-class Subs and Functions. The language acquired the Class keyword somewhere around VB4. Not true classes in the OOP sense, it didn't support inheritance. A feature missing from the underlying COM architecture.
It doesn't fit very well with the execution model provided by the CLR. There is no support for free functions, every method must be a member of a class. The VB.NET compiler emulates modules by declaring a class, the module procedures become Shared methods of that class. You can see this with Ildasm.exe:
.class private auto ansi sealed ConsoleApplication1.Module1
extends [mscorlib]System.Object
{
.custom instance void [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute::.ctor() = ( 01 00 00 00 )
} // end of class ConsoleApplication1.Module1
Note how it is private, so that code can't get a reference to it, and sealed, so that no code can derive a class from a module.
The C# compiler does the exact same thing with a "static class", the CLR doesn't have a notion of static classes either. There are plenty of good reasons for static classes, the idea of "Module" isn't obsolete. You could accomplish the same by declaring a NotInheritable Class in VB.NET code, having only Shared methods. The VB.NET compiler however doesn't enforce methods to be Shared like the C# compiler does and doesn't allow you to declare the class private. As such, a Module is just fine.
Modules are the closest thing VB has to static classes, which can be very useful, even when programming in an object-oriented environment.
And since VB has no static classes, modules are as far as I know the only way to create extension methods.
You need modules in order to define your own Extension methods
My VB project is large enough that it requires several files. It was originally developed as a Console App and I created each file as a MODULE. All modules could use subroutines, data structures and constants from other MODULES and everything worked fine. I needed to add basic windowing to the app and this required that the app be converted from a Console App to a Windows Forms App. The main window is Form1 which is not a MODULE but a CLASS. The problem is that some MODULE based functions cannot access subroutines, data and constants that are defined within the CLASS Form1 unless they are incorporated into the CLASS file and this makes the CLASS file very large. If I add a new Class file to the project, it also cannot interoperate with Class Form1 in the same way that multi-MODULE code interoperates.
How does one spread CLASS code across several files and still allow it to interoperate as if it were in a single file? Alternatively, how does one create several CLASS files that operate the way multiple MODULE files operate.
I am sure that there are all kinds of best practices that I am violating but the goal to to get some prototype software working and interfaced to some lab equipment.
Thank you in advance
Use a partial class (Partial keyword on the class declaration). Each partial "bit" of the class will be merged at compile time. All partial bits must be in the same project.
Modules are default shared and do not require initialization with the New keyword. When you made your console app a windows app, it became a class...You could change it to the same behavior as a module simply by making it a Public shared Class and making all properties and methods inside shared as well.
so while you can access your methods and properties in your modules without initialization, you would need to use the NEW method to initialize your Class methods.
To access the Class from the module you would simply have to use:
SomeModulemethod
dim x as new CLASS
CLASS.SOMEMETHOD
someModuleMethod End
You could also use Partial Classing to split up your Classes, but it is much better to decide if you really need a separate class for what you want to do.