With OOPhoto, not only am I trying to learn object oriented programming in ColdFusion, I'm trying very hard to be able to explain every decision that I make. As far as I'm concerned, if I can't fully explain the choices that I make, then I probably shouldn't be making them. Today, it occurred to me that I have never explained, nor fully thought out the way in which I choose the storage of my internal component variables. Let's do that now.
If you look at my objects, you will see that I use two different component structures for data storage:
While one of these is contained within the other, they have two very different and distinct purposes. I can feel this difference very strongly, however, I am not so sure that I can gracefully put this difference into words.... but let's try.
What I think it comes down to is the concept of object-instance uniqueness. Let's say that I have to compare one object to another and that this comparison is the aggregate of the comparisons of all the "relevant" properties of each component. I say "relevant" here because that is the critical factor when it comes to storing our component properties. For deciding object-instance uniqueness, there are simply properties that are not relevant.
To explore this concept, let's look at a really small example, Dog.cfc. Imagine that Dog.cfc has these three properties (pseudo code notation):
- DSN (Data source name)
Now, imagine we have two instance of Dog.cfc. If we wanted to compare these instances to see if they were the same object, which values would we compare? Obviously, the Breed and Age are crucial - if one Dog has a different breed, then clearly these are different instances. As such, these two properties are very relevant to the object-instance uniqueness.
But, what about the DSN property? Theoretically, these two object-instances could have different DSN values; however, in the context of the "known" application - of our application - is this ever going to happen? No, it's not; all database interaction throughout my application will be done using the same DSN. Therefore, the DSN property of this class, Dog.cfc, is not relevant to object-instance uniqueness.
Ok, so now that we have a better understanding of what a "relevant" component property is, let's define the storage rules:
All properties that are relevant to object-instance uniqueness shall be stored in the VARIABLES.Instance struct.
All properties that are not relevant to object-instance uniqueness shall be stored in the VARIABLES scope.
Because the relativity of properties will change from context to context, we can't get any more specific than that. But, I believe that these rules are very clear in their intent and will allow me to explain my property storage decisions.
That being said, what happens when we have a Singleton object? A singleton is meant to have only one instance, so how can we apply a rule that involves the comparison of object-instances? That's easy - when you are dealing with a singleton, which can never be compared to like-instance, none of the properties of that singleton are relevant. As such, all properties of singletons should be stored in the VARIABLES scope.
Sometimes, it feels so good to write something out in words. Now, I never have to worry about property storage - that's decision is in the bag.