Yesterday morning, I launched phase one of OOPhoto, my latest attempt at learning object oriented programming (OOP) in ColdFusion. And, while this is an attempt at learning OOP, phase one consisted of a working application written entirely with old-school procedural-style code. I was getting so caught up in the thought process of creating an object oriented style application that I was slowly slipping into analysis paralysis. To get past this problem, Dan Wilson and Peter Bell suggested that I just bang out the fastest, simplest solution first, and then worry about refactoring it into OOP later. So, that's what I did:
The site, while quite small, was much more complicated that expected because of the AJAX commenting and photo uploads. While a seemingly simple feature, it adds a lot of overhead to the application (at least in my amateur way of doing it). Plus, I think the fact that the application has both internal (ColdFusion) and external (AJAX) touch-points will make it a better overall leaning experience when we convert the application to object oriented programming complete with remote facades.
Yesterday afternoon, after launching the application, I took a trip down to Systems Forge to meet with Peter Bell. Peter was kind enough to sit down with me and go through my procedural style application pointing out ways in which it could be refactored. He mentioned several things, including a conversion to CFC-based controllers; but, in the end, we felt that the easiest first step for an OO-n00b like me would be to create simple Service objects to factor out my queries. Now, this doesn't really make my project more Object Oriented, but it does move me in that direction and it certainly encapsulates my queries and cuts down on repetition (keeping my system DRY'er that it was originally).
Furthermore, I am going to have the Service Objects simply return queries. I love the query, I know the query, I am friends with the query, I think the query looks great in overalls - I'm not ready to cut her out of my life just yet. I will worry about different types of return values later on in my journey.
Defining the service objects and methods was simply a matter of walking through the application and defining the "intent" of each of my queries. Here is what I have come up with:
That's all the SELECT-style queries that I have in my application. And I say "SELECT-style" because you might notice that there are no persistence-oriented queries in my service objects; I have decided to leave the persistence for later. For now, I am just going to concentrate on pulling out information in a refactored way.
While this step is rather small in that it is only taking queries and moving them into objects, it will end up serving several important purposes:
It will get me more comfortable with getting my information from objects rather than hand coding all my queries for each page. Not only will this cut down on my repetition, it will also force me to not worry about optimizing every query for every page. By that, I mean that I will have to become comfortable that a query might return more information than is needed on a given page. You might laugh, but this is an odd point of control to give up.
It will get me more comfortable with Factory-created objects and dependence injection. While I am new to object oriented programming (OOP), I am familiar with some CFC "Best Practices". With all my queries being moved to CFCs, I know that I have to start injecting my DSN information into the object for use in the CFQuery tag (such that the CFC does not need to know about the universe outside). This will be a nice and easy first step before I get into more complicated dependency injection issues later on.
Ok, time to code my Service Objects.