Instantiation

In object orientation, there are 2 terms you will see used a lot. One is class, and the other is object. Sometimes they seem to be interchangeable. But there is an important concept to grasp here.

When we code a CFC, what we have is really a blueprint, a class in object oriented terms. So essentially, the word class refers more to the blueprint that you write in code.

So for this example, let's create a CFC and call it Person.cfc

You can see clearly when looking at this particular code sample that it is just a blueprint, in other words a class. A person has a name, but in our code, no specific name is set. We could create representations of many different people with this code block and set their individual names differently.

So in ColdFusion, when we use the CreateObject() function (or the cfobject tag), and in many cases assign a variable to the object we create so we can refer to it later in our code, we are creating an instance of the class Person. Let's do that.

So the above code block is an example of instantiation. Instantiation implies usually 2 things, creating an instance of a CFC, and doing the necessary to prepare that instance for use. In our simple example, we used the init() function to set Tom's name.

Essentially, it's similar to using the StructNew() function to create a structure and then populate it with data. With a structure, you assign a variable name to the new structure so you can use it, and then you set the necessary values in the keys.

Let's take a closer look at our Person CFC. Remember that in OO speak, people would refer to this as a class.

By convention in ColdFusion, the init() function is where you prepare your CFC for use, and as we said before, this is often implied in the term instantiate. You will also sometimes find the word initialize used to describe this step. In this simple example, it doesn't make much sense to have a Person without a name. So the init() function has a required argument for the name of the person, and it's specified that it should be a string.

What this shows me as a developer working on a project, just by looking at the code, is that you should always pass in a name when you instantiate a Person. We could have just created the object and used the setName() function instead to pass the name into the CFC ... but then it wouldn't be indicated clearly in our blueprint that setting the name should be part of the instantiation of the object.

You'll also notice that the setName() function is private, meaning that this method can only be accessed from within the object. This makes it "impossible" to change an InstanceOfPersonCalledTom's name to Fred. We've determined, as a "business rule", that it shouldn't happen that the name of a person changes in our simple example application. So building our blueprint with setName() private indicates that to other developer working on our project. Once the name is set at instantiation, it shouldn't change.

We could have also not bothered including a setName() function and just made the init() method in our blueprint like this:

At first glance to the writer of the blueprint, that might seem more simple and clear. But if another developer comes along and sees it (or you look at your own code in a few months!), they (or you!) could interpret this in 2 ways. One is that the author of the code was being lazy and didn't write a setter for Name. Or they also might conclude that excluding the setter meant that setting the Name should happen at instantiation.

But if the init() function calls a private setName() method as below:

then our blueprint is unambiguously clear.

You'll also find going along that more experienced OO programmers always use setters and getters in their objects. Even tho' that often adds more code to your blueprint, there are good reasons for that.

If you look closely at the init function, you'll see that besides accepting an argument called "Name" and using the setName() function to set the name in the variables scope of our Person instance, it also returns "this".

In a CFC, "this" has a special meaning. It means the whole CFC instance - all the methods and data within it are contained in the variable "this".

Returning "this" in the init() method allows you to do what is called "method chaining". So instead of

You can do

... which instantiates your object in one line of code, which many programmers find a little clearer. As pointed out in the comments below, instantiating your object in one line of code like that in cases where your object is instantiated into a persistent scope is important because it makes it "thread safe".

You'll find example code returning "this" in the init() method in many cases.

So to review, when you instantiate a CFC, which would be called a class in object-speak, what you get is an instance, an object that you can use in your code. A class is like a blueprint, and you can instantiate many object instances from a class.

The term instantiate also implies preparing your object for use. And depending on what that object's responsibilities are, it could simply include setting a few simple values, or running a series of complex calculations from several functions that utilize the capabilities of other objects and setting the results in a variety of other objects.

So we've answered a few questions, but a reader new to CFC's and object orientation will have more questions from the above arising in their mind. For instance:

If a structure is so simple to use, i see just 2 lines of code up there, why should we bother with all the complication of objects? What advantage do they have over a simple, easy to understand struct?

And what's this "passing" term mean? You said you "passed" a name into the init() function. Why can't you just set it in the request scope? That way you could forget about the init() function, and the setName() function, and just have a getName() function that simply returns request.tomsName. In fact, in this case, you don't even need the whole Person object. You can reference request.tomsName from anywhere in the app. So again, if using the request scope is so easy, why bother with using a complicated CFC?

And you know, there's another thing. I hear people talk about getters and setters all the time on the lists, and i see a getName() and setName() method here. Isn't there a simpler way to set a variable in these things?

And i don't get this line:

What does that do? Why use the variables scope?

So it looks like we have a few more questions to answer in the coming days about the bare bones basics of using CFC's in an object oriented manner in ColdFusion. A few more might even show up in the comments!