[XPost Reddit, LONG] Tutorial on Classes vs Structures

**rileyjstrickland** · 11-01-2015

Section I & II are basics on classes and structures, skip to section III if you already know these!

Section I - What are classes and structures?

Classes and Structures are, by the MSDN definition

Classes and structs are two of the basic constructs of the common type system in the .NET Framework. Each is essentially a data structure that encapsulates a set of data and behaviors that belong together as a logical unit. The data and behaviors are the members of the class or struct, and they include its methods, properties, and events, and so on, as listed later in this topic.

Now, just what the hell does this mean? Well, in essence, a class and structure are "types" of objects (the things like buttons, panels, etc.) that holds information such as methods, properties, and much more.
Before we continue, it should be noted that in many other languages, such as C++, the difference between a class and a structure are much smaller than in VB.Net.

Why should we use classes and structures? Well, it's really quite simple. Take this example:

Code:

    public class car  
        public mileage as single  
    end class

With this class "car" we are able to define objects of "car" that will hole the mileage. This is extremely useful if we need to store a bunch of variables, and need to have multiple of said items. Not only this, but we can add things like events (example: button1.click), methods, and even properties.
Now, how do we know that we have a class or structure? Well, we know because it's a "type" and not an "object." For the rest of this tutorial I will refer to classes / structures as "types," except for a small section where I distinguish the differences between them.

Section II - Class Basics

What is a property?, an event?, heck, what's the purpose of methods in a class?

The only really easy way to describe these is to break them down. An event is a bit like a forwarder. It takes parameters like methods (it technically is one), but does absolutely nothing with them. Instead, it acts as a "trigger" for another method to "handle" it based off of the forwarded parameters. For instance, when you click a button, nothing actually happens except for the button.click event firing. When you double click the button on the visual editor it creates a sub to "handle" the event. In there we add our code, so that each time that the button is clicked, our sub is executed. A really nifty thing that we can do is handle multiple objects with one sub, this is where parameters come in very handy.

Now, just what the heck is a property?
A property is nothing more than a glorified sub, no really. It however has much more utility than a sub due to how the IDE works.

Properties have things called getters and setters, and like their name, they "get" and "set" the property's value. The one really useful feature about properties is that you don't have to write a sub called set_var and get_var, but instead write get and set(value as object). This doesn't seem to save you code, but when you go to set / get you don't have to call set_var and get_var, but instead call the property by name.
I know you must be thinking, why should I use these!? I can just make my variables public / friend and set them from within my own program! Well, they're useful for keeping local global variables private and for validating the information that you are trying to feed into the variable. For instance, if I have an unsigned integer called x and use x = -1, my program will crash, but with a property called x, I could use x = -1 and have the setter check for < 0 and "fail" to set the property.

The usefulness of methods in a class is simply code re-usability, and for making "generic" methods that can be overridden and shadowed, and for being able to do something like:

Code:

    dim a as myclass  
    if a.validiate() = false then  
        'oh no, not valid!  
    end if

Section III - When to use a class, and when to use a structure

MSDN provides a checklist for when you should use a structure.

It logically represents a single value, similar to primitive types (int, double, etc.).
It has an instance size under 16 bytes.
It is immutable.
It will not have to be boxed frequently

Should you follow this checklist? Yes actually, for most situations.
Types such as integer, byte, single are all structures. This means they can not be inherited. Inheritance only takes place within classes.
So, when should you not follow the checklist? Almost never, but I personally found a few situations where you can't follow it.
They are, as follows:
Needing to convert your Object into an unmanaged byte array (for interacting with things such as a local file that is a C++ structure.)

Why?

Classes are instantiated as "references", which is essentially a pointer in C/C++. Why is this important? Well, you can't write out a pointer, it never actually holds the value, it simply holds the address where the value can be found in the ram of your computer. If your class only has structures you might get away with marshaling it, but the moment a class is introduced in your object as a variable you can't*
*You "can" if you convert sections of the object and compile the final array, but that is a giant pain in the ass.
When should you use a class over a structure irregardless of the checklist? Ironically, the exact same situation, but inverted.

In a method if you pass your object as byref all changes to the passed object get passed out to the original object. If we pass our object as byref into a blocking function (a function that waits until some condition is complete), but copy it into a global variable within the other object that we passed it into, a structure copies the value like a byval into the global variable, while a class will correctly create a reference (pointer) to the original. Take the following code for example:

Code:

    Public Class DankNumberC  
        Public x as Integer  
    End Class  
    Public Structure DankNumberS  
        Public x as Integer  
    End Structure  
    Public Class DankAdder  
        Private mine as object 'didn't feel like making two vars for the things :)
        Public Sub Add(byref thing as DankNumberC)  
                mine = thing  
                domath()  
        End Sub  
        Public Sub Add(byref thing as DankNumberS)  
                mine = thing  
                domath()  
        End Sub  
        Public Sub domath()  
                mine.x = 4 'total legit math rite here
        End Sub
    End Class

If we use A for our class, and B for our structure and call "Add" from our DankAdder (Let's call it C) then the following will happen.
A.X will be 4, but B.X will remain unchanged.

If there is interest in these tutorials I'll continue to write them and I'll go into some more in-depth details of the language.

Some sources:
https://msdn.microsof*****m/en-us/library/ms229017.aspx
https://msdn.microsof*****m/en-us/lib...hs(VS.80).aspx
Really nice StackOverflow response: https://stackoverflow.com/questions/3...nsidered-nasty

This is my own tutorial I wrote on Reddit, re-posted on here.
https://www.reddi*****m/r/visualbasic...vs_structures/