none
Declaring a Class from a Module RRS feed

  • Question

  • Hi

    Reading various VB.net code fragments I have noticed that small Classes (e.g. a class for decoding a menu OR a series of names/addresses) are included in a Module.vb and not in a Class.vb.   I have seen that the Module.vb sometimes has Subroutine / Class / Subroutine etc.    Should ALL Classes be added to a Class.vb and never included in a Module?  Should each and every Class have its own namespace in a separate Class.vb no matter the length of code.  Any advice would be appreciated.


    Margarita_Cody

    Friday, June 19, 2015 6:29 AM

Answers

  • The answer is, it depends. Class and standard code Modules have different uses, so really it could boil down to an issue of preference and coding style. The below link describes the differences:

    https://msdn.microsoft.com/en-us/library/7825002w%28v=vs.90%29.aspx?f=255&MSPPError=-2147217396

    Classes lend themselves to a more OO (Object Oriented) design, so that would be one reason to choose them over Modules, but then there is less setup work accessing Module code vs. Classes. But there is no reason to choose one in exclusion of the other. It's certainly fine to use both where you see fit.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Friday, June 19, 2015 1:03 PM
  • Modules are generally special case objects in VB.

    If you're going by code you've seen scattered across the net, then in many cases you may be looking at people doing things an old way because they don't know any better (or refuse to change), or you may simply be looking at poor design patterns.

    While I agree with Paul that it is fine to use both where appropriate, I would also say as a general rule of thumb for a beginner to stick with classes until you do something which requires a Module (like extension methods).  If you use modules to store application data you are likely to end up with messy code which is easily broken as you add more complexity to your program.  If you stick with classes you'll be forced to learn/use object oriented design principle and you'll likely end up with cleaner code which is easier to maintain and expand.

    Namespace usage is generally up to you; organize your objects into namespaces when and how it makes sense.  Generally your project only needs individual namespaces when it gets really large and contains a lot of different objects with different intended functionality.  For many small to medium sized applications, additional namespaces may just be clutter.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Friday, June 19, 2015 2:59 PM
    Moderator
  • Each VB program has always one module. In that is the Sum Main method. 

    Currently does it mostly contains only few lines of code and is meant to start a program. However in old style console applications it is mostly the only place where code is. 

    It looks like this

    Module Module1
        Sub Main()
        End Sub
    End Module

    If the application framework is used, then this code is behind the scene.

    A Class (and then not a shared class which is only a different name for a module) is not something in which code runs. You instance from that an object. From a Class you can instance more times objects. In a normal program are currently thousands of classes. To order those they can be placed in a namespace or/and in class libraries.

    Using currently a program with modules is in fact programming likewise in VB1 with VB12.


    Success
    Cor


    Friday, June 19, 2015 3:29 PM
  • One more thing to add to the current replies, working with classes except for modules required for language extension methods as Reed pointed out is if you ever work with C# there are no code modules and language extension methods are within static classes.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my webpage under my profile but do not reply to forum questions.

    Friday, June 19, 2015 6:42 PM
    Moderator

All replies

  • The answer is, it depends. Class and standard code Modules have different uses, so really it could boil down to an issue of preference and coding style. The below link describes the differences:

    https://msdn.microsoft.com/en-us/library/7825002w%28v=vs.90%29.aspx?f=255&MSPPError=-2147217396

    Classes lend themselves to a more OO (Object Oriented) design, so that would be one reason to choose them over Modules, but then there is less setup work accessing Module code vs. Classes. But there is no reason to choose one in exclusion of the other. It's certainly fine to use both where you see fit.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Friday, June 19, 2015 1:03 PM
  • Modules are generally special case objects in VB.

    If you're going by code you've seen scattered across the net, then in many cases you may be looking at people doing things an old way because they don't know any better (or refuse to change), or you may simply be looking at poor design patterns.

    While I agree with Paul that it is fine to use both where appropriate, I would also say as a general rule of thumb for a beginner to stick with classes until you do something which requires a Module (like extension methods).  If you use modules to store application data you are likely to end up with messy code which is easily broken as you add more complexity to your program.  If you stick with classes you'll be forced to learn/use object oriented design principle and you'll likely end up with cleaner code which is easier to maintain and expand.

    Namespace usage is generally up to you; organize your objects into namespaces when and how it makes sense.  Generally your project only needs individual namespaces when it gets really large and contains a lot of different objects with different intended functionality.  For many small to medium sized applications, additional namespaces may just be clutter.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Friday, June 19, 2015 2:59 PM
    Moderator
  • Each VB program has always one module. In that is the Sum Main method. 

    Currently does it mostly contains only few lines of code and is meant to start a program. However in old style console applications it is mostly the only place where code is. 

    It looks like this

    Module Module1
        Sub Main()
        End Sub
    End Module

    If the application framework is used, then this code is behind the scene.

    A Class (and then not a shared class which is only a different name for a module) is not something in which code runs. You instance from that an object. From a Class you can instance more times objects. In a normal program are currently thousands of classes. To order those they can be placed in a namespace or/and in class libraries.

    Using currently a program with modules is in fact programming likewise in VB1 with VB12.


    Success
    Cor


    Friday, June 19, 2015 3:29 PM
  • One more thing to add to the current replies, working with classes except for modules required for language extension methods as Reed pointed out is if you ever work with C# there are no code modules and language extension methods are within static classes.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my webpage under my profile but do not reply to forum questions.

    Friday, June 19, 2015 6:42 PM
    Moderator
  • Many thanks for all the very helpful advice.  Greatly appreciated.

    Margarita_Cody

    Saturday, June 20, 2015 10:35 AM
  • Hi

    Reading various VB.net code fragments I have noticed that small Classes (e.g. a class for decoding a menu OR a series of names/addresses) are included in a Module.vb and not in a Class.vb.   I have seen that the Module.vb sometimes has Subroutine / Class / Subroutine etc.    Should ALL Classes be added to a Class.vb and never included in a Module?  Should each and every Class have its own namespace in a separate Class.vb no matter the length of code.  Any advice would be appreciated.


    Margarita_Cody

    Typical me ... always a day late and a dollar short.

    *****

    I'd like to add to this: As Reed said, use a module when it's appropriate but I'll expound on that some. When is it appropriate? My answer to that is "only when there's no other way to do it". An extension (also as mentioned by Reed) would be a prime candidate for that.

    As Cor alluded to, a module is like a shared class (no such thing in VB Net) in that it's never out of scope.

    For what it's worth. :)


    Still lost in code, just at a little higher level.

    :-)

    Saturday, June 20, 2015 11:33 PM
  • I really appreciate Paul P Clement's comment "so really it could boil down to an issue of preference and coding style"

    My stance lies in my previous forum signature which was "coding is like fresh baked bread - - it goes stale after a while - - so why immortalize it and turn it into a classs???"

    Now in your coding experience, do you think that in 2 years time, you are going to need a class that you wrote today? Maybe, but in my experience NO, you will write something fresh and new that does essentially the same thing - but in a more modern sense - with your added experience superior to your original effort.

    Thats why I propose to keep modules as they currently are, and not to force everybody to start "classing" everything.

    As per link in Paul's post above : -

    The main difference between classes and modules is that classes can be instantiated as objects while standard modules cannot. Because there is only one copy of a standard module's data, when one part of your program changes a public variable in a standard module, any other part of the program gets the same value if it then reads that variable. In contrast, object data exists separately for each instantiated object. Another difference is that unlike standard modules, classes can implement interfaces.

    And as per KevinInstructor's post, about C#, I know nothing about C#, but it would sadden me if you could not use the module concept in C#, and maybe I would skip C# and just go straight for C++ if VB dies.


    Top Tip: Toothache? Cut paper towel to 2"square. Smear with olive oil. Sprinkle on Cayenne Pepper. Fold over few times to form small wad. Tuck in between wall of mouth and gum. Leave 1 - 2 hrs. You will thank me!


    • Edited by LeonCS Sunday, June 21, 2015 6:41 AM
    Sunday, June 21, 2015 6:40 AM
  • Leon,

    Your messages says in fact: "I do not work in a team and am just a beginner who is still learning from what I make".

    Modules lead always to spaghetti code whatever you do to prevent that as soon as a program grow. 

    With Classes and Class libraries that is not the case.


    Success
    Cor


    Sunday, June 21, 2015 7:31 AM
  • Yes Cor

    Classes may be more appropriate for so called "team" environments. But as always it is 'horses for courses'. And everything else you alluded to is very 'subjective'. 


    Top Tip: Toothache? Cut paper towel to 2"square. Smear with olive oil. Sprinkle on Cayenne Pepper. Fold over few times to form small wad. Tuck in between wall of mouth and gum. Leave 1 - 2 hrs. You will thank me!

    Sunday, June 21, 2015 7:50 AM
  • Modules lead always to spaghetti code whatever you do to prevent that as soon as a program grow. 

    With Classes and Class libraries that is not the case.


    Success
    Cor


    Don't think so. There is nothing specific to a standard module that leads to spaghetti code, which deals with the flow of logic and branching within the code itself. Spaghetti code can be written in any type of module. 

    Paul ~~~~ Microsoft MVP (Visual Basic)

    Sunday, June 21, 2015 12:55 PM

  • Don't think so. There is nothing specific to a standard module that leads to spaghetti code, which deals with the flow of logic and branching within the code itself. Spaghetti code can be written in any type of module. 

    Paul ~~~~ Microsoft MVP (Visual Basic)

    Yes we agree Paul, therefore they invented classes. Can also be done knitting, but mostly they are small and reusable if it is done by a little bit educated programmer.

    :-)


    Success
    Cor


    Sunday, June 21, 2015 2:12 PM