In the previous tutorial covering functions, I explained how you can use them to break the flow of your applications. Instead of your application running linearly, you can selectively call certain parts of your application to come alive when you want to. That's what functions bring to the table.
Now, we are going to go one step further. As you know by now, functions are a good start at making your application more modular:
True modularity comes from breaking your application up even further. What we are going to do next is look at how to break your application up into self-contained, mini-applications:
This isn't me being crazy. What I am going to do is help you gently dip your toes into the giant pool known as Object Oriented Programming (shortened to OOP).
Generally speaking, OOP is a method of organizing and implementing your program in an easily handled and portable manner:
[ pictures of Legos taken from wikipedia ]
Instead of focusing on functions to handle operations in your program, objects are used to contain and control information. These objects can contain not only information, but also the methods (functions) needed to control it. As such, objects are self-contained and unreliant on other aspects of the program. This makes them easier to deal with and, you guessed it, more portable when used again in other applications.
Before really getting into the thick of it all, some basics need to be covered. The goal is to provide the information in an easy to understand fashion. So without further ado, let's continue and start by looking at...objects!
At a very high level, an object is a blob:
This blob can contain things inside it. The things it can contain are stuff like numbers, strings, functions, or even other blobs:
Despite how scary a blob may seem, you will never see a blob by itself. It will almost always be tethered to a host. The host in our world is a variable:
Beyond just being a good friend, this variable acts as the gatekeeper to the blob and anything it stores inside it. You cannot get very far with the blob without first becoming friends with the variable as well.
The blob in this example represents an object. In the context of OOP, an object is in many ways a self-contained, small application. Within its bounds, an object can contain state, variables, numbers, strings, functions, and more. It can even contain other objects. It's pretty disgusting really.
Learning how to work with objects and their nuances will seem a little boring at first, but once you understand their magic language, the rest of the OOP concepts will seem like a walk in the park.
Let's start walking!
The best way to learn more about objects is to create and use one yourself. The code for making a generic object is as follows:
We define a new variable called myObject, and we initialize it to a new object by using the new keyword followed by calling the Object constructor. I will cover constructors in greater detail in a future tutorial, but just know that it is something you can use to create objects.
Getting back to this line of code, after it has run, it will result in you creating a generic, empty object of type Object that is assigned to your myObject variable:
Now that your object is created, you can do all sorts of objectionable (ha!) things to it like filling it up with stuff:
The way you populate an object is by first referencing its variable:
Then you use the dot to go into the object itself:
Once inside, all you need to do is pick a property name and assign it to something:
In our code, I am creating new properties inside my object called name, num, isMyFirstObject, and showHello. Each of these properties does something different. The name property stores some text, the num property stores a number, the isMyFirstObject property stores a boolean, and the showHello property actually points to a function. Pretty Modern Family to me!
If you had to visualize all of this code in the context of our blob, here is what you would see:
To retrieve values from an object, you will use the same dot syntax you used for specifying your data in the first place:
The only difference between then and now is that I am not assigning any value to my property. Once I reach the property with my dot notation, I just back away slowly.
You don't have to use new Object() for creating a new object. Just like Arrays, objects also have a shorthand method of declaration. Arrays, for example, can be declared in one of two ways:
Similarly, objects can be defined in two different ways:
Using the shorthand version, like with arrays, you can make internal variable assignments inline. This way, you won't need to keep referencing the myObject variable to repeatedly add values to it:
Here, myObject is an object declared with the name and value properties already defined. Note that this method is for initial definition only. You cannot add values to an object in this manner. For that you would need to access the object variable directly for each new value as done previously.
One important thing to be aware of with objects is that object variables are references to objects. As references, object variables aren't necessarily direct representations of values but rather pointer reference to the object in as it exists in memory:
[ object variables "point" to objects ]
One way to think of them is by looking computer shortcuts (or aliases for Mac folk). Think about a shortcut to Microsoft Word on your computer's desktop:
[ a shortcut is just a pointer to the actual file ]
Double-clicking on the shortcut will open Word as it references the actual Word application file. However, you can rename the shortcut to whatever you want without affecting Word itself. You can copy the shortcut 20 times in 20 different locations on your hard drive and that Word application file these shortcuts point will still be the only ‘real' file remaining in the same place its always been:
Each one of those shortcut copies will still reference that same one Word application despite them being a copy or being located in some other directory.
Object variables are the same way. You can make new variables with different names equaling the same referenced object. The thing is, when referencing variables within an object, you have to remember each one of those object variables that point to that object will all be accessing the same values within that object. So, if you change a value through one object reference, it affects them all.
Consider the following:
When firstObject is created, it is saved as a reference to the new Object made in memory. Using firstObject to reference that object, num is added and given a value of 1. Then, secondObject is defined to be the value of firstObject. This makes secondObject also a reference to the same object:
[ both firstObject and secondObject point to the same thing ]
To extend our Word example from earlier, both firstObject and secondObject are shortcuts to that object. You can see that the num value in secondObject exists and has the same value as before. When secondObject is used to change num to 2, the results can be seen in firstObject as well, since, they are in fact, again, just references to the very same object:
This means, as you can pretty well see, copies of objects in this way aren't exactly copies. Only the reference is copied and not the object itself. If you ever need to copy an object, you need to create an entirely new object and manually copy each property from the original as a new property in the copy.
Inequality and equality are interesting in this world as well. Because objects are references, when you check for equality/inequality with either the == or != operators, you will be checking against the references themselves and not the equality of the object they reference. The firstObject and secondObjects from before are equal. They reference the same object, so as references, they are the same.
However, if you had two separate objects each with a num property of the same value, they will not be equal.
Though the contents of firstObject and secondObject are the same, they are themselves not equal as they reference separate objects:
Behind the scenes, the reference isn't representative of value but of a memory address. You can think of it as the address to a house in a neighborhood of similar houses. Though 2 houses can look exactly the same and even have the same furniture in them, they are not the same house. Their addresses will be different as they are located in different locations in the neighborhood, just as objects are located in different places in your browser’s memory. The only time object references equal each other is when the addresses match. Then you are dealing with the same house and therefore the same object.
As you will see shortly, you can define the structure of your own objects and create object variables that reference instances of your custom objects. That is what makes objects awesome. You can define your own blob and everything about it, and you'll learn all about how to do that in the next tutorial.
If you have questions, need some assistance on this topic, or just want to chat - please drop by our friendly forums and post your question. There are a lot of knowledgeable and witty people who would be happy to help you out. Plus, we have a large collection of smileys you can use
Did you enjoy reading this and found it useful? If so, please share it with your friends:
Until next time, see you all later!