Not so fast! You may recall from the discussion above that one of the hallmarks of an object is that it's self-contained. What does this mean? In addition to meaning that the object's data and the methods for working with the data are both contained within the object, it also means that you should never (and in most cases, well-designed objects won't let you) set an object's data directly as illustrated above. A good object will contain methods that will allow other objects to access its data as needed, and the polite OO behavior is to use these methods - and only these methods - to interact with the object. You don't want to be seen as rude on your first visit to ObjectLand, do you?

Don't Touch My Data... At Least Not Without Asking
Only using an object's methods to access its data brings up another OO concept called encapsulation. In brief, encapsulation refers to the situation I described above whereby you only interact with an object through the methods it exposes to you. For something simple such as retrieving a Person object's first name this may seem like overkill (why not just grab the data directly?), but let's consider another example. If you were to have an object that contained a method that had to perform relatively complex operations to return the requested data to you, you shouldn't have to know (and probably don't even want to know!) what the object is doing to return that data.

In this sense an object and its use of encapsulation are like a telephone. You just plug the phone into the wall, pick up the receiver, and you get a dial tone. You don't know or care about what's going on in the wiring, switching, etc., you just want to get a dial tone. This is exactly what encapsulation does. It provides an interface for you to use to get what you need without requiring you to know what's going on behind the scenes. This is important for simplicity and ease of use, to protect the object's data, and to keep things from breaking in the future. Imagine if you had to reconfigure your telephone every time the phone company got a new piece of hardware on their network!

Encapsulation protects you from having to modify your code if the implementation of a particular operation in an object changes. This could be as simple as changing the way a value is calculated or as complex as changing from a relational database to an XML-based data storage system. Regardless of the specifics involved, encapsulation will keep your OO systems humming right along even if a relatively drastic change has to be made to an object within the system.

Beans: They're Not Just a Breakfast Food
(with Apologies to Johnny Cash)
To summarize the idea of encapsulation, any code that interacts with an object should never modify the object's data directly. In procedural programming variable values such as someone's name are modified directly, but as we'll see in a future article this leads to problems that we can avoid with good OOP. This is why a best practice in OOP involves the creation and use of methods within objects known as getters and setters (also referred to as accessors and mutators). These are simple methods that allow us to retrieve and set values of data within objects through method calls, as opposed to accessing the data directly.

If an object has getters and setters for each of its attributes, it is actually a specific type of object known as a bean. The bean concept comes from the Java world, where everything is related to coffee in one way or another, so I suppose that's as good an explanation as any for the name. A bean is a type of object that is very commonly used to represent real-world constructs such as a Person, Computer, or Car. There are of course other types of objects you'll be using in OOP, but in my experience if people grasp real-world objects (which in turn are usually beans in OO systems), it's a lot easier to start working with other types of objects as well. The CFC example we'll see at the end of this article will technically be a bean.

Returning to the example above, after we create our matt object we'll want to set the values for matt's attributes so the object is no longer an empty shell of a Person. You've probably already surmised that since we can't access the object's data directly, we're going to be using the object's get and set methods to interact with the matt object. Let's tell matt what his first and last names are by using the object's setters for these attributes:

matt.setFirstName("Matt");
matt.setLastName("Woodward");

As you can see, the set methods take a single argument, a string, to set the values of first and last name. Once these values are set, we can then turn around and ask the matt object what its first and last name is by using the object's get methods:

<cfoutput>The matt object's first name is #matt.getFirstName()#, and
the matt object's last name is #matt.getLastName()#.</cfoutput>

I hope you're already starting to see how this can simplify many of your programming tasks. Once an object is instantiated and the data is populated within the object (and even that step isn't terribly complex), you simply ask the object for its data and can use it wherever it's needed. This makes for clean, flexible code that's easy to use and maintain.

Object Constructors
The final concept I'll address in this article before moving on to the specific code for our Person CFC is the concept of a constructor. A constructor is a method within a class that provides the means to construct the object. What this construction operation usually involves is setting any default data that's absolutely necessary for the object to function correctly once it's instantiated.

In the case of the bean object we're discussing, you can use this constructor method to create the object and set all of the attribute values rather than setting each attribute's value individually. Most objects will have what's called a "no-arg constructor," which means that if you want to instantiate the object but don't have the object's attribute values right at that particular moment, you can simply create the object, pass the constructor method no arguments or data, and the constructor will handle anything that's absolutely essential for that object to exist.

At this point we've hit upon one of the first differences of CFCs as compared to other OO languages such as Java. CFCs do not have the concept of a constructor. In Java, to create a new object you typically do something like this:

Person matt = new Person();

Because in Java the constructor method shares the same name with the object itself, that Person() call will invoke the object's constructor method. Let's revisit how we created our CFC objects earlier:

matt = CreateObject("component", "Person");