An object generally knows only about itself, the data contained in its own variables scope. In order for an object to know about external data, it needs a way to "see" it. Passing data into an object, often only when it is created, is called data injection.
Crossing the border
In order for an Object to know about external values (either from a CFM or from another CFC), data needs to be injected into it. Anything placed in the object's variables scope exists for the life of the object and is available to every function inside it.
Now let's pass in a value for "foo" from the CFM page.
At this point, "foo" exists in the variables scope of the CFM file, while another distinct variable named "foo" exists in the variables scope of the CFC (object).
Since the variables scope of the CFM and the variables scope of the CFC don't know about each other. Changing the value of "variables.foo" outside of the object does not change the value of "variables.foo" inside the object.
The same is true when we inject the value of a session variable into the object.
Let's add a function to Object.cfc that adds 4 to the value of variables.foo:
<cfset variables.foo = variables.foo + 4 />
Now what happens to a variable external to the object when we change the value inside the object?
The value of variables.foo inside the object was originally defined by the value of session.foo. When the value inside the object is changed, session.foo is unaffected. This sounds perfectly reasonable, so why does this bear mentioning?
So far, we've only been talking about passing simple data values into an object. Later we'll talk about passing objects as arguments in order to build more complex objects. When we talk about object composition, we'll re-visit session variables and objects.
For many types of objects, it's best to only set data into the variables scope through the constructor when the object is created. This is especially true when those objects are placed into the application, session or server scopes.
However, data can be passed into an object through any public or remote function. Those functions can then place that data into the object's variables scope. Doing so after an object has been created has its pros and cons, but these vary depending on what type of object you're using.
Why insulate objects?
An object has a task or set of tasks and often shouldn't know about the outside world.
Much like Milton from Office Space, if an object can gain access to another object it shouldn't know about (like a check for millions of dollars) or can change the value of shared scope variable at any time (i.e. server.officeIsOnFire = true), it may end up burning your application to the ground and retiring to Jamaica.
We've talked about many different variable scopes:
- variables (outside an object)
- variables (inside an object)
Before we get into specific types of objects, we have to cover the var scope and why it is the most important and most overlooked scope in object oriented development with Coldfusion.