Question Using a Class to pass variables between forms

divjoy

Well-known member
Joined
Aug 25, 2013
Messages
159
Programming Experience
1-3
Hi,

I'm not user where to post this so feel free to move it if its in the wrong place. I'm using vb.net 201 express and ql server 208r2

I am developing a system where I am using about 10 global variables. From reading online a lot of users prefer to store there global variables in a class with accessor methods and other non related methods and pass an instance of the class to each Form as required, this is easier than passing a long list of global variables and offers some level of encapsulation while implementing the OOP paradigm.

My dilemma is tho, if the class members are not related in any way to one another, for example ClientID, StaffID, UserID, ComputerID, and members like CalcTotals etc. this is surely wrong, as there is no object of this type, that has all these disparate elements and thus, is not modelling the real world?

Isn't it just another case of using a model for convenience rather than for the purpose it was intended, thus while I know using global variables is less secure, it is more honest.

Isn't creating one global class to hold all global members and methods, not just circumventing the system for our own convenience.

I am interested in hearing everyone opinion on this matter and what they would do/have done in this situation and what they have learned from it, because I feel I am going to have to do this too.....
 
All fields and properties are members of something so you're already doing what you're arguing against anyway. Whether you declare them all in a module or all in a class as instance members, they're all still members of the same type so you're still artificially grouping them regardless.
 
froms v classes

I'm not really arguing against it i'm just pointing out an observation.

I'm curious as to what people are doing?

Another examplw would be when I have a form (class) called frmClients, to use it I would type frmClients.show()

But really I should be typing...

Dim frmClient2 As New frmClients

frmClients2.Show()
 
I'm not really arguing against it i'm just pointing out an observation.

I'm curious as to what people are doing?
Step 1, avoid global variables if at all possible. Step 2, if you need global variables then you have to put them somewhere so they are inherently going to be grouped based on the fact that they are global rather than representing any cohesive entity regardless. Many people would use a module in VB.NET. Some who feel (incorrectly) that modules violate the principles of OOP might use a singleton class. Personally, on the very few occasions that I actually need something like this, I add a property to the MyApplication class and then I can access it via My.Application in code, which seems appropriate given that a global variable is logically a member of the application.
Another examplw would be when I have a form (class) called frmClients, to use it I would type frmClients.show()

But really I should be typing...

Dim frmClient2 As New frmClients

frmClients2.Show()
I'm not sure that that really relates to the subject of global variables. Default instances, which you've demonstrated there, basically provide singleton functionality for forms that aren't actually defined as singletons. They are intended to make VB6 developers feel more at home and to make it easier for beginners to communicate between forms but there is never an actual need to use them. Personally, the only time I'd use them is when I specifically want singleton behaviour, e.g. clicking a button will activate an dexisting form if there is one or open a new one otherwise.
 
Hi J,

Thank you fro your clear explanation, there si quite a debate going on, n the internet about singletons and their OOP credentials.

Still I have an open mind on it and would love to see some code that created these singletons and what might be associated with it.

So if anyone has any please post... thanking you
 
Implementation of the singleton pattern is very simple. You make the only constructor Private and then add a Shared property that returns the one and only instance, e.g.
Public Class Singleton

    Private Shared _instance As Singleton

    Private Sub New()
    End Sub

    Public Shared ReadOnly Property Instance As Singleton
        Get
            If _instance Is Nothing Then
                _instance = New Singleton()
            End If

            Return _instance
        End Get
    End Property

End Class
 
Back
Top