Hal Helms On Object Oriented Programming - Day One

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:

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.

What Other People Are Searching For

[ local search ] object oriented programming classes
[ local search ] oop classes for coldfusion
[ local search ] classes on object oriented programming
[ local search ] classes on oop and coldfusion
[ local search ] learning oop class
[ local search ] coldfusion oop class

You Might Also Be Interested In: