When we modularize our code base into CFCs using Object-Oriented Programming principles, our objects will often begin to rely on other objects to function as intended. When one part of our application relies on another part of the application to function, we have what is called a dependency. While we want our objects to know how to use the objects that they depend on, we do not want our objects to be responsible for creating and configuring the objects that they need – we want to maintain loose coupling and keep a separation of concerns.

In order to keep a separation of concerns we want to manage any dependencies between objects outside of the objects themselves. This can be accomplished by leveraging an Inversion of Control (IoC) framework such as ColdSpring. ColdSpring features a design pattern called Dependency Injection (DI) to help to assemble the components needed for the application to work. Dependency Injection manages the dependencies between objects by … wait for it … injecting the dependencies into the objects that rely on the objects to function.

The following demo application is an simple example on how to use ColdSpring to manage your object dependencies in your application.

In my previous post I explained the use of remote proxies to access Singletons in Application scope. I thought that I would elaborate what a Singleton is for those who might be late to the design pattern party (better late than never!). A Singleton is a design pattern where an object is instantiated … wait for it … a single time. That’s right the object is created only once and is stored in a scope where it can be globally accessed.

In many of today’s popular ColdFusion frameworks, a common practice being utilized is storing instantiated objects in the Application scope as singletons. This becomes problematic when we need to access an object stored in the Application scope but the request comes from outside of the application (such as remote calls through AJAX). So what do we do when we want to access these objects remotely? Well, you can’t -- at least not directly.

The solution to this accessibility problem is to instead interface with a remote proxy in place the original inaccessible object. Some of you may be wondering, “What is a remote proxy?” Some of you may be wondering the same thing while simultaneously scratching your head. Some of you may be wondering how I know what you’re thinking and doing as you're reading this blog post (but I digress).

A remote proxy is a specific type of Proxy Pattern. To help illustrate what a proxy is, here is a great analogy from JavaWorld:

A friend of mine -- a medical doctor, no less -- once told me that he convinced a friend to take a college exam for him. Someone who takes the place of someone else is known as a proxy. Unfortunately for my friend, his proxy drank a bit too much the night before and failed the test.

So for our case a remote proxy is an accessible object that takes the place of the inaccessible object. Think of it as a substitute object. Got it? Great.

Broadcasting live from my little grass shack in the middle of the Pacific Ocean the City of Angels in sunny Southern California, I proudly present the new and improved randolphlinmark.com 2.0! *waits for the cheering to subside*

After having packed up all my things, moving from Hawaii to Los Angeles, and starting a new job while getting acclimated to a new city, I finally find myself comfortably settled into my new surroundings. Unfortunately, one of the byproducts of the hectic past few months was that I neglected blogging or updating my site.

So after months of neglect I felt it was time for this site to start a new – a rebirth if you will. All previous blog entries were purged and is now a distant memory dancing around aimlessly in the cyberspace abyss. The total extreme makeover included switching blogging engines and skinning it with a newer more-edgy design.  So with renewed vigor and enthusiasm I will start by writing the obligatory "introductory" blog post to summarize this blog in a nut shell.