Why Object Oriented at All?
"why do we go to all this trouble when the life of a page is only 54 ms?"
Very cool :->
Of course, the real lifetime of a web page isn't 54ms - it is the months or years that you have to maintain it. OO is just a set of proven solutions to maintainability problems that might come up and the reason that OO can seem hard to learn is because we’re often trying to learn patterns (solutions) to problems we haven’t encountered just yet.
For me the perfect example was ColdSpring. I can honestly say that I had never sat down and said "if only I had a dependency injection framework to provide an IoC container for my objects – THEN I’d be done with my projects faster".
Then I listened to Dave Ross’ great ColdSpring presentation at CF United and I finally realized the problem it solved and suddenly DI and IoC made sense as descriptions of a problem I was just starting to have. Without the problems, the patterns are meaningless, and while it would be nice to "get" OO upfront, it’s better to just absorb all of the articles and blogs so when you see a problem you have that OO might solve, you can try a cfc here or there and see if it won’t help you out.
The biggest thing to realize about OO is that it takes longer to do. Even when you are an OO guru, perfectly cohesive domain models and perfectly formed service layers will not come tripping from your fingers like pixie dust. OO means more typing upfront. However, if you’re ever going to have to maintain those applications (and I am scared by how many people are still using applications I "threw together" in the 90’s) OO saves you time and trouble down the line.
Once I’ve got my basic framework up, I’ll try to make sure I post at least one "OO 101" every month to try to provide some more resources for people just getting started with OO. The goal of the series will be to look at the problems you might come across (in the Design Patterns world they’re called "forces") and how common OO approaches can help you to solve those problems elegantly.
My problem was I didn't know the proper names and all. IOC and containers, etc, I just called it a factory, XML configurable, something simple enough to just work. It wasn't until I had a working model that I started to pay attention to ColdSpring and decided to switch over.
Meanwhile, I continally tell myself that I've really got to finish my head-first design patterns book :)
Thanks for the comment! Right, you had an app with a set of stateless components calling each other and you had to figure out how to make it work. In my experience if you don't have an OO background, you write your user service (assuming you're going down the stateless service level supporting domain objects avenue). You then add an address service and realize they need to speak to each other, so maybe you instantiate them in application scope.
You then figure out that isn't so great, so you create an application.Factory so at least you only have a single dependency on application.Factory.getObject(ObjectName). Then you notice your factory is getting pretty complex and repetitive - especially handling the dependencies between objects as your model gets more sophisticated. So, you encapsulate what varies and break out the configuration information into an XML file. Then you see someone has done this already (thanks Dave and Chris), you play with it and you port to ColdSpring and you're done. My point is that until you've enough going on that just throwing your singletons into application scope is a problem, ColdSpring is a solution to a problem you don't yet know that you have!
Definitely finish off the book - its cool. I'm through it about three times and I'm picking through the original GoF book, but to be honest, the only patterns I feel like I really "own" are the ones that have solved problems that I realize I have. I think that until you have the problems, all you're doing with design patterns is fertilizing your mind so that when you drop in the seed of a problem it might trigger something and you'll go see if a decorator or adaptor or whatever might meet your needs.
I find almost all design patterns completely obtuse in the abstract and almost glaringly obvious once you need them and use them! The forces don't just drive the patterns - they also drive the comprehension of the patterns. Until you get sick of writing createObject() all the time or wonder how you could encapsulate the configuration of your objects, even something as simple as a factory is pretty tough to grasp!
Best Wishes,
Peter