Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with:

Hal Helms On Object Oriented Programming - Day One

By Ben Nadel on
Tags: ColdFusion, Work

Yesterday afternoon, I arrived in Sarasota, Florida to attend Hal Helms' one week seminar on Object Oriented Programming. I don't know if the planets where in the right alignment or what, but I got wind of this class last minute and just my luck, there was an opening. This is ultra exciting for me. As you saw last week, I have been looking for a ColdFusion Object Oriented Programming class to help organize all the information flying around in my head, so this is like a dream come true (please excuse the fanboy, throwing my bra on stage mentality, but let's face it, Hal is the guy you wanna be learning this stuff from).

So here I am sitting down at the end of the first day and I am exhausted. I feel both mentally and physically drained. There is so much lose knowledge saturating my brain. I can't wait to go to sleep just to start letting is marinate like a fine steak. The first day was great. I know that I missed the classroom setting, but I forgot just how great it really is; the whole day was all about sharing ideas and working through "scenarios" with our collective problem solving abilities. It was like an 8 hour in-depth conversation about object oriented programming.

During the class, I think I had a really good mental breakthrough in regards to the Service layer of an application. We kept throwing around terms like domain object, service object, business object, model, controller, etc.; so, we decided to take a minute to define some of these objects to ensure that we were all on the same page. I recommended that the Service layer be thought of as the "Controller" to the model in very much the same way that the Controller is the "Controller" for the View half of the application. So, for example, in the same way that the Controller translates the request, "user.login", into a View, the Service layer translates simple requests like AuthorizeUser() into a whole series of model-based events (think: log user-login to database, update user permissions, trigger any alerts necessary). In their own way, both the Controller and the Service layer act as a Facade to the implementation of each request.

Another great conversation we had was about the layers of specificity of an application and the rules about cross-layer relationships. This concept was based on the Fundamentals Of Object-Oriented Design In UML By Meilir Page-Jones. In his book, Page-Jones describes the "horizontals" of the code based being divided into four groups. I don't remember what they were exactly, but it was something like this:

  1. Interface
  2. Application
  3. Domain
  4. Foundation

The idea here is that the farther you go down the list, the less application-specific classes become and therefore more reusable. So, for example, the foundation horizontal would contain things like String, Money, Angle, and Float; these are the most basic, most reusable components. Then, as you get into Domain, and Application, you get classes that are increasingly more specific to your application and therefore less reusable.

The reason this is important is because keeping a class reusable requires that the dependency of classes only go from high to low. For example, you can have a class in the Domain horizontal require a class in the Foundation horizontal, but you would never want a Foundation class requiring a Domain class (think: Money having a reference to a Product class).

That being said, this conversation really got me to question some of what I do in my application. Well, not the beginning of the conversation, but the latter half. After lunch, Hal gave us a modified Horizontal breakdown (he did not author this, but found it online):

  1. User Interface View
  2. User Interface Control
  3. Domain Process
  4. Domain Entities
  5. Data Access
  6. Data Storage

The part that really got me thinking was this concept that the "Process" objects where more specific than the "Entity" objects. If you think about it, there is some good sense to this. An object is less specific that the actions which get applied to it. In my OOPhoto application, one rule that I came up with is that a business object (Entity) should know how to leverage its data. Often times, it can do this by passing the message up to its parent Service (or related service). For example, a PhotoGallery object might have the following method:

  • function GetPhotos(){
  • VARIABLES.PhotoService.GetPhotosForGallery( THIS.Get( "ID" ) )
  • }

I have been enjoying this, but you can see that it violates this rule about specificity. In my solution, the Entity object (PhotoGallery) needs a reference to a Process object (PhotoService) which is more application specific. This hurts the reusability of the domain entity (ie. PhotoGallery) as it couples itself strongly to an object that is more tightly bound to the given application.

At the end of the conversation, we actually got rid of the 6-tier horizontal model because the "Data Access" objects (think DAO) almost always have references to the "Domain Entities" (think Business Object being persisted). The 4-tier list that Meilir Page-Jones suggests seems to make more sense since it leaves several of these layers in the same horizontal which allows some relationships to stay horizontal rather than cross verticals in a violation of direction.

Now, you may be asking yourself why this was a useful conversation if we eventually ditched part of the idea? The point is really that we are flexing our thinking muscles; we're examining new ideas and keeping an open mind and we're all helping each other make progress. The magic of it all is really hard to put into words, but I have no doubt that the next 4 days of idea-cross-pollination will lead to many more breakthroughs.

I'm so jazzed, but I need to crawl into bed now and let my subconscious tackle all of this stuff.

Note: Another thing I wanted to talk about is how bad it is to program before you understand the use cases. This could have easily and logically been tied back into the concept of prototyping... but I am too tired to get into that.

Reader Comments

This may be a dumb question, but I don't think you listed the _official_ class name, and Hal's site seems to be a bit behind. Was the class: Designing and Developing OO Applications with CFCs?

Thanks for giving us a summary of your day. Interesting reading. Totally agree with your last para "how bad it is to program before you understand the use cases." It can be a fatal mistake, we're all code junkies and just want to code, but it really is worth taking some time out first :)


I just learned about the class last minute. I don't actually know what the name of the class is. I think its the upper level OO class (I think he teaches a beginner class as well, which I am skipping ;)).


The weather is beautiful! And the lizards are too cute.


Yeah, we ran into that problem very fast at the end of the day working with Accounting (and none of us really know accounting workflow).


Love the insight about specificity you shared. When you first blogged about your bottom-side up object -> service calls (VARIABLES.PhotoService.GetPhotosForGallery), it really bothered me, but I couldn't defend what was wrong with it, so I didn't comment on it. You've nailed it, though: it's upside down, in terms of architecture, reading 'back up' to get a function call, instead of only laterally or 'down'. Brilliant encapsulation of the concept.


That looks really awesome. I am a huge fan of all things monkey / ape related. That's way cool that your wife used to work there. I don't think I'll have enough time to make it over (the classes goes kind of late), but definitely if I come back down here for more relaxation.


Yeah, I think it makes sense that you don't want to reference up the chain. It's interesting - I'm really trying to change the way I think about this stuff.

@Rick O,
Those places look great! I've lived in Tampa Bay for ~18 years and never knew about them. I'll have to take my son there. I'm sure he'll get as much of a kick out of it as I will.

Ray, the class is "Real World OO". Tonight we have everyone over to our house for dinner. This is a great bunch of developers.

Thanks for the ID Hal. Where is the best place to see your list of upcoming classes? Your site seems to be a bit out of date. (Or am I looking in the wrong place?)