Store and retrieve through classes - Functions, Subs and best practices

Question

After completing a computer science degree I've landed a job as a software developer (woo!). Through university I was heavily web programming orientated sticking to Javascript and PHP (in the procedural sense). I'm now jump into object oriented programming as well in Visual Basic .NET.

I want to start on the right foot with best practices and what not so I have a simple scenario I want to know what the best way to do it is.

Let's say I have a class called 'Config.vb' which in the and on creation the 'Sub Load' reads keys from the registry. Keys are: 'Fname', 'Lname', 'address1', 'address2', 'city', 'shoesize'.

So I want to stored these keys and their values accessible to my Main.vb.

First approach would be to declare 6 variables to stored the values so

Dim firstName = regKey("firstname").value
Dim lastName = regKey("lastname").value...

Then to have accessor methods to retrieve these values

Property ReadOnly getFirstname As String
 Get 
  Return firstName
 End Get
End Property

But writing out 6 get methods seems to be too lengthy. I could well be wrong, this is why I'm asking; is this the best way to access these variables?

Alternatively,

I was thinking maybe bunching all the keys and values in just the one Dictionary variable so it would contain all the keys with their values, then just having the one function to that accepts the key string and returns the value like:

Private Function getkey(key) As String
   Return dictionary.Item(key)
End Function

This is probably how I would approach it.

Any guidance or let me know your way doing it will all help me and other to learn better!

Thanks.

If you want Best Practices, dont store app data to the Registry. There are lots of other options starting with My.Settings — Ňɏssa Pøngjǣrdenlarp, Jan 29 '16 at 20:31
If the data is really something like Settings/Config, [This answer may help](http://stackoverflow.com/a/25319489/1070452). "showsize" infers app data, if there is not enough to bother with a database, [See this answer](http://stackoverflow.com/a/33529974/1070452) (very similar to each other except for context) — Ňɏssa Pøngjǣrdenlarp, Jan 29 '16 at 20:41
Ah I see, thanks for the help I didn't realise it was such bad practice! I think I'm going to rewrite the class now! — MikeS, Jan 30 '16 at 14:23

David Wilson · Accepted Answer · 2016-01-30T19:33:54.723

As Plutonix said. Storing data in the registry isn't a good idea. Depending on how you want to access the data. If you just want to read all the data about lots of (presumably) people into your program in one go then you could check out object serialization or if you're dealing with large amounts of data check out databases.A good start with basic OOP can be found here. Its quite an old article, but should still work just fine.

As far as your data is concerned, you're better defining a new class. Like this

Friend Class Person
    Dim _firstName As String
    Dim _lastName As String

    Public Property FirstName
        Set(value)
            _firstName = value
        End Set
        Get
            Return _firstName
        End Get
    End Property

    Public Property LastName
        Set(value)
            _lastName = value
        End Set
        Get
            Return _lastName
        End Get
    End Property
End Class

Private Sub Form1_Load(sender As Object, e As EventArgs) Handles Me.Load

    Dim p1 As New Person
    p1.FirstName = regkey("firstname")
    p1.LastName = regkey("lastname")

End Sub

Of course if you're dealing with several people then you'll be better creating a list. Instead of declaring p1 as a new instance of a person, decleare the list like this

Dim peopleList As New List(Of Person)

and add people list this

    Dim tempPerson As New Person

    tempPerson.FirstName = regkey("firstname")
    tempPerson.LastName = regkey("lastname")
    peopleList.Add(tempPerson)

or

    tempPerson.FirstName = "Fred"
    tempPerson.LastName = "Perry"
    peopleList.Add(tempPerson)

The beauty of OOP is that within a class you can declare methods(procedures) that work with the data in each instance of the class for example. say you have a property in you class called DOB - list this

Dim _DateOfBirth As Date

Public Property DOB As Date
    Set(value As Date)
        _DateOfBirth = value
    End Set
    Get
        Return _DateOfBirth
    End Get
End Property

You can create a function in the class like this that returns the person's age without ever having to store and update the age as time goes by. Like this:

Public Function Age() As Integer
    Age = DateDiff(DateInterval.Year, _DateOfBirth, System.DateTime.Now)
    Return Age
End Function

To get the age of the tempperson, just use this

    Dim tempPerson As New Person
    tempPerson.FirstName = "Fred"
    tempPerson.LastName = "Perry"
    tempPerson.DOB = CDate("8/12/1967")
    MessageBox.Show("Age of the person is " & tempPerson.Age)

Gotta love OOP!

Awesome answer, thank you for going into so much depth. I'm actually referring to just keeping the one copy of this data. Really good to know if there was multiple people I'm keeping track of. If I was to keep one copy of the info for, let's say it's info about the user, is it still better practice to make all the private variables accessible through multiple Get Property methods? — MikeS, Jan 30 '16 at 14:17
Yes I would say so. Using accessories methods you can include code there to validate the data internally and if the class is ever used elsewhere, you have validation built in rather than having to write it again, or if you de ide to change the validation code, you only have to do it in one place. Rather than in two separate projects — David Wilson, Jan 30 '16 at 14:36
Your `Age` function wont compile under `Option Strict`. Since Dates do not have a format (that is converting to string), `DateDiff(DateInterval.Year, _DateOfBirth, System.DateTime.Now)` is all you need. Constructing it as a Function is common, but of you look at most of the NET class methods like `Count` which do something similar they are ReadOnly Properties — Ňɏssa Pøngjǣrdenlarp, Jan 30 '16 at 14:48
I meant to mention why on the property thing. If you had a `List(of Person)` to be used as a DataSource, `Age` is something you might expect to see or be shown. When it is exposed as a Function that aint gonna happen - wrapping it in a ReadOnly Property allows it to show up in a DGV etc. I personally dont like more than a line or 2 in Getters, so I tend to still have a private function ([example](http://stackoverflow.com/a/35119970/1070452)) — Ňɏssa Pøngjǣrdenlarp, Feb 01 '16 at 00:17
Quite true - This was just a quick bit of code to show a tiny bit of what you can do with OOP at the basic level. — David Wilson, Feb 02 '16 at 10:11

Store and retrieve through classes - Functions, Subs and best practices

1 Answers1