Difference Between a Class and a Module

What is the difference between a module and a class?

A class is a type. You can use this type like any other type (String, Integer, Date, FileInfo ...) to declare variables, parameters, properties, and function return types.

Let us make a little example:

Public Class Person
Public Property FirstName As String
Public Property LastName As String

Public Overridable Sub Print() 'I will explain Overridable later.
Console.WriteLine($"{FirstName} {LastName}")
End Sub
End Class

Now you can declare variables of type Person

Dim sue, pete As Person
Dim persons As List(Of Person)

sue = New Person()
sue.FirstName = "Susan"
sue.LastName = "Miller"

pete = New Person()
pete.FirstName = "Peter"
pete.LastName = "Smith"

persons = new List(Of Person)()
persons.Add(sue)
persons.Add(pete)

For Each person As Person In persons
person.Print()
Next

Whereas modules are static. I.e. Data stored in a module exists exactly once. On the other hand, you do not have to instantiate a module with New, therefore they are often used to store global data and for methods that are available globally. For instance, you could store the persons list in a module.


But there is much more you can do with classes. You can derive a class from a base class. This new class inherits everything from the base class and can add more stuff to it. For instance, you could derive an Employee class from Person

Public Class Employee
Inherits Person

Public Property Salary As Decimal

Public Overrides Sub Print
Console.WriteLine($"{FirstName} {LastName}, Salary = {Salary}")
End Sub
End Class

The Overridable keyword in Person.Print allows deriving classes to re-define (to override) the Print method. (Functions and Subs in classes are called methods.)

Employees are assignment compatible to Persons. You could add an employee to the persons list. This does not require any change in the For Each loop, i.e., the call of person.Print() automatically calls the right Print method (the first one for "normal" persons and the second one for employees).

Dim emp as Employee

emp = New Employee()
emp.FirstName = "Frank"
emp.LastName = "Taggart"
emp.Salary = 3500.00D

persons.Add(emp)

There is much more to say about classes. I hope that you got a certain idea of what you can do with classes.

See Objects and classes in Visual Basic and especially the section Differences between classes and modules.

Difference between a class and a module

The first answer is good and gives some structural answers, but another approach is to think about what you're doing. Modules are about providing methods that you can use across multiple classes - think about them as "libraries" (as you would see in a Rails app). Classes are about objects; modules are about functions.

For example, authentication and authorization systems are good examples of modules. Authentication systems work across multiple app-level classes (users are authenticated, sessions manage authentication, lots of other classes will act differently based on the auth state), so authentication systems act as shared APIs.

You might also use a module when you have shared methods across multiple apps (again, the library model is good here).

Difference between Module and Class in Python

  • Module:

    A module is a file containing Python definitions and statements.

As the doc say.

So a module in python is simply a way to organize the code, and it contains either python classes or just functions.
If you need those classes or functions in your project, you just import them.
For instance, the math module in python contains just a bunch of functions, and you just call those needed (math.sin).
Just have a look at this question.

On the other hand a python class is something similar to a java class, it's only structured in a slightly different way.

What is the difference between Class program and module program in VB.net

The difference between a Module and a Class is subtle; there is only ever one instance of a Module in all your program's life, and you cannot make multiple instances of it using the New keyword. By contrast you have to make an instance of a Class before you can use it..

In order to run, the .net framework runtime has to be able to find an available Main method without having to create an instance of a Class. This is achieved either by having the Main be kept inside a Module (and thus the Main is available because the module is available without having to instantiate a Class) or having it declared as Shared and be inside a Class (in which case you can conceive that a special thing happens that makes the shared Subs available without a class instance)

It's a hard difference to explain if you're not really well introduced to the concepts of OO programming and what "instances" actually means:

Class Person
Public Name as String
Public Sub New(n as String)
Name = n
End Sub
End Class

This declares a class of type person. Nothing about it refers to a particular person and it doesn't cause any Person object to exist in the computer memory until you use New:

Dim cj as New Person("Caius Jard")
Dim g as New Person("gxmgxm")

g.Name = "gsmgxm" 'correct a typo! this edits the name in the g object. it leaves cj's name alone

Now two instances of a Person object are in your computer memory, one named for me and one for you. You cannot do this with a Module. If we'd declared Person as Module there would only be one of them in all the entire program, accessed by the reference "Person":

Person.Name = "Caius Jard" 
Person.Name = "gsmgxm" 'this overwrites my name. The program cannot remember more than one Person

and we couldn't have multiples. Consider that, at the time you launch your program, the runtime finds everything that is declared to be a Module and creates just one of them. This is somewhat vital for all sorts of advanced reasons that I won't get into, and Modules definitely do have their place in the grand scheme of things but thy aren't always incredibly useful in OO programming because more of the time we want more than one instance of a thing so we can model multiple things simultaneously.

So that's a precis on Class vs Module and why they are. In order to call any Sub or Function, you have to be able to call it on something. You have to have a DVD player before you can put a DVD in it and press Play - equally in programming, you have to have something that you can put your Main sub on, so you (or the .net runtime) can refer to it with Program.Main() and execute the instructions of the Sub.. That's how Subs and Functions work - theyre either associated with the special single instance (if it's a Module or a Shared Sub/Function of a Class), or they're associated with some object instance in the computer memory, and calling the Sub/Function acts on the object instance that was referred to:

Class Person
Public Name as String
Public Sub SetNameBlank()
Name = ""
End Sub
End Class

cj.SetNameBlank() 'the name of the cj object we declared before, is now blank
g.SetNameBlank()

By specifying the object instance name cj then the Sub name, we establish context - the actions listed in SetNameBlank will be carried out against the cj object, not the g one. If we'd declared SetNameBlank as Shared then they would have taken place in the shared context, not related to either cj or g, and Shared SetNameBlank() could be invoked without cj or g even existing

Going back to the reason you're asking your question right now, what the difference between these two (in the context of a "Main" Sub), the answer is..

..is "not much" from the perspective of getting your app going. Either approach is fine. Your Main method will have to start kicking things off my making object instances of the other Classes you have in your program and getting them to do things. It probably wont make new instances of the class that your Main is in so right now it doesn't really matter whether you put your main in a module or a class - it achieves the same end result that there is a Sub the runtime can call into to start things moving, without needing to create an instance of a Class first

https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/program-structure/main-procedure

What are the practical differences between a module method and a class method in Ruby?

tl;dr: There are no class methods and module methods in Ruby, only instance methods. Considering that they are both just instance methods, and thus the same thing, there cannot possibly be any difference.


There is no such thing as a "class method" or a "module method" in Ruby. Ruby has exactly one kind of method: instance methods.

We sometimes use the word "class method" or "module method" out of convenience when talking about a certain pattern of using instance methods, but there is no such concept in Ruby. "Class methods" and "module methods" are really just singleton methods of an object which just happens to be an instance of the Module class or the Class class. There is absolutely no difference whatsoever between a singleton method of an object which happens to be an instance of Class, Module, String, Array, Hash, Object, Foo, Bar, Whatever, or Garbledigookidoo.

Oh. Did I mention? Singleton methods don't exist, either. Again, it is a word we use for certain kinds of usages of methods, but they are really just regular boring old instance methods of the singleton class of an object.

However, "instance method of the singleton class of foo" and "instance method of the singleton class of Foo, where Foo is an instance of Class" are really long, and so we shorten them to "singleton method of foo" and "class method of Foo" out of convenience, knowing full well that those are fictions that don't actually exist in the language.

Unlike Java, which has three different kinds of methods (instance methods, static methods, and constructors (which are kinda-sorta like methods)), Ruby has exactly one kind of method: instance methods. No class methods, no module methods, no global methods, no top-level methods, no static methods, no constructors. It does, however, have three kinds of classes: regular classes, singleton classes, and include classes (the latter being classes that get synthesized and injected into the inheritance hierarchy when you call include or prepend). These classes differ mainly in whether methods like Object#class, Class#superclass, and Class#ancestors display them or suppress them. Singleton classes are suppressed by all of them, include classes by the first two, but shown by ancestors.

Classes vs. Modules in VB.NET

Modules are VB counterparts to C# static classes. When your class is designed solely for helper functions and extension methods and you don't want to allow inheritance and instantiation, you use a Module.

By the way, using Module is not really subjective and it's not deprecated. Indeed you must use a Module when it's appropriate. .NET Framework itself does it many times (System.Linq.Enumerable, for instance). To declare an extension method, it's required to use Modules.

What is the difference between modules and class modules in Access?

Of course you can create objects in vba:

If you named your classModule: "YooClass" then you can create a object by:

Dim myObject as YooClass
Set myObject = new YooClass

I also create a non-class-module called ObjectFactory with this code:

Public Function Yoo(...) As YooClass
Set Yoo= New YooClass
Call Yoo.Init(...)
End Function

this works as a constructor. So I can write:

Dim myObject as YooClass
Set myObject = new Yoo(...)

or call a function directly like this

Call Yoo.MyFunction(...)

This is some kind of a "static" function-call (or as close as you can get in vba).

If you want more information about classes in VBA (or in general): There are a lot of tutorials for this with a lot of explanations and examples. Like this: https://analystcave.com/vba-vba-class-tutorial/

TypeScript: What's the difference between a Module and a Class with Static members?

Modules allow you to structure and separate your code. Depending on the module type that might be file based (for the external/es6 modules) or namespace based (for the internal modules), spread across multiple files.

There are multiple reasons to use modules instead of classes, like packaging and loading. Also, you can't declare a class inside another class, so unless you can structure your code in such a way that one class is enough to encapsulate an entire feature they won't be able to replace a module.



Related Topics



Leave a reply



Submit