After the CFUG meeting last week, a few of us took a minute to celebrate the holiday and drink some green beer. :)

What came from that conversation was some good discussion from all parties on how they use OO in their design and development practices. I found myself sitting on the fence through most of the discussion emphasizing that although I had done these things via OO (i was previewing some code) there was nothing in there that could not be done procedurally.

I have found that I am have a better than average grasp of design patterns and OO design practices, but in this discussion I felt the need to be my own devil’s advocate. This is not my usual method for things. My friends know that when I get excited about something I become a preacher, spouting the ways of righteousness to all within ear shot. So I am wondering what was different about this dicussion that put me on the other side of things?

Well anyway, I came away from that meeting feeling like we had a very good discussion. And then this week I found a couple good articles that cover some of the topics we discussed. So I thought I would share those here for all to enjoy.

The first is another one of Hal Helms discussion peices. In this peice he and Jeff Peters discuss how to look at OO design to make sure you are representing it correctly. They also discuss that although fusebox and mach-ii differ in thier internal designs, the OO aproach that you apply to your domain can be used in both. You can find thier conversation here

The other link I would like to share is from an article over at Java Devlopers Journal. This article called Beyond Patterns: Thinking Objects is a great discussion of an Idea i have tried to share here frequently. That concept is this. Although design patterns are a great tool for OO developers, learning Object Oriented design by studing them is kinda like putting the cart ahead of the horse. Design patterns are a way to reference common trends in software architecture. But if you have not put in the time actually doing OO design, then there are many concepts that will be foriegn making the learning task very difficult. Understanding what the “Abstract Factory” pattern is is very difficult to understand without actually having come upon a reason to need it.

In the end this article although it was published on JDJ, is a great intro for CF developers who are looking to learn how their code can benifit from CFC usage. So to learn more about the shift of designing procedurally to designing Object Oriented please take a look.