More Thoughts On OO Design
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.
"learning Object Oriented design by studing them is kinda like putting the cart ahead of the horse"
So true! You can emulate the pattern ’til the cows come home, but without understanding the forces that cause the need for the pattern, and how OO design is used inside the pattern, your use will be very limited.
I’ve recently been stealing and locking up people’s copies of Head First Design Patterns until they read The Object Oriented Thought Process and give it some time to sink in.
Thats a good idea. at least trade it for Head First Java and make them take a trip to Objectville :)
Yeah, this is also why I continually caution against copying example code – if you don’t understand why the code works the way it does, you won’t know whether it’s appropriate for your problem. Design patterns are the same kind of thing – each design pattern has multiple implementations and unless you understand the motivation and forces behind the pattern, you won’t be able to make the right choice.
Get it working, then get it right – build it and refactor it.