Objects and Frameworks - Taking a Step Back
Posted on Jul 12, 2006
So the Boston CFUG had our meeting tonight, and following Peter Farrell's excellent Subversion and Trac presentation, the group had a discussion that moved into people's use of frameworks. After polling the group, I was surprised to learn that not 1 person (out of about 20) was currently using a framework (we did have 2 ex-Fuseboxers who missed it). I then polled the group to see if anyone was using an object-oriented style of development at all without a framework, and no one was. Despite my surprise, my guess would be that other groups might not be all that different. I have absolutely no criticism of this, and the group was obviously following and interested in the topics of OO and frameworks. It made me think that maybe we as a community need to take a step back and refocus on helping others to make that transition, as it can seem quite intimidating. I am going to share a little bit about my experience in the hopes of starting this (and try to follow up with some other posts covering making this transition).See, I am no OO or frameworks expert. Actually, it was not to long ago where I was completely frustrated with OO. I had been trying to learn some basic Java and Java development practices and concepts. I had read The Object-Oriented Thought Process to try to solidify the concepts, and yet, I was thoroughly frustrated. I had been so comfortable creating what Matt Woodward once called "spaghetti with meatballs" (which was moving your queries into components but still doing procedural code).
As for frameworks, I had studied Fusebox since version 3. I had looked into Mach II when it first came out (yes, I remember it as Fusebox MX) and I was clearly not ready for the concepts it presented. I had even walked through all the documentation that was available on Model-Glue, but felt the transition and work involved seemed overwhelming. Still, I had read the blog posts of people I respected and thought I understood why using a framework could improve my applications.
Still, I had a long list of excuses not to use a framework - a lack of time or needing to train others who felt more reluctant towards them on the team, etc. Finally, I went to cf.Objective() and had a brief conversation with Sean Corfield. I don't know Sean very well though he has always been nice to me the couple times we have met, but I wouldn't be divulging any big secret by saying that Sean can be quite blunt. I explained my situation and his response was essentially (I am paraphrasing here), "Stop with the excuses and just do it."
I didn't do that right away, but in the end I did follow his advice. It took one blatantly obvious observation that had somehow eluded me. You see, I kept looking for the silver bullet to doing OO correctly - the Rosetta Stone so to speak that was going to make it all make sense to me. Finally one day it kinda hit me that no such thing exists...that even people like Sean and Hal Helms and others who I saw as experts on the topic did not even have this. Ask them (and I don't mean to speak for them) and they will tell you they are still learning OO so to speak and that there is no single OO solution. The point is, it is ok to do it wrong because that is part of the process. So, go ahead and do it wrong, and when you know a little better, refactor it.
As for frameworks, well the same rules apply. Just do it and don't be afraid to do it wrong. In the end it isn't as intimidating or difficult as it may seem once you dive in. As this post has already gotten quite long, I will revisit these topics in more detail later if people think they are useful, but hopefully shedding a little light on my experience can help others to take the plunge.
Comments
I agree with you. Moving to a OO methodology, does imply more brain cells and it can be overwhelming. Specially, when you see that you are sometimes writing more than you should or complicating your development. However, there is the pay offs. Your code is more modular, you can follow design patterns, WHICH WORK!! and overall, you begin to experiment with techniques that will at the end of the day surprise you.
However, you do need to invest the time and effort to dig in your heels and give it a shot. There is no excuse not to. Try all the frameworks out, build your own, learn learn learn.
The best way to learn is to actually give it a shot, get involved. There is no silver bullet or a magical wand for your development. However, there are these gold coins that you can use that will give value to your projects and help out.
Posted By Luis Majano / Posted on 07/12/2006 at 10:47 PM
I had such a conversation with Sean Tuesday. In short, my question is "why do we go to all this trouble when the life of a page is only 54 ms?" And yes, Sean was blunt and really didn't answer the question. I'm already a big fan of OO, but when it comes to web applications, I don't really get the point of OO. So in a way, I am looking for "Rosetta Stone" that would help me wrap my mind around web OO.
Your post makes perfect sense and now that I feel I'm not alone in the way I think, it makes it esasier to excetpt what I don't yet understand.
Thanks for a giving me the guiding light that will let me take my mind off the 'stone' and get back to web OO. I look forward to collection a few coins.
Posted By Gary Funk / Posted on 07/13/2006 at 5:07 AM
Hi Gary, The point of OO is to use other peoles mistakes so you can get home earlier in the evenings. That's it.
Firstly, how big are your applications? If you're writing a single page form processor I think it's safe to say that Mach-II with Coldspring and Reactor might just be a bit of overkill.
Start with something simple. Do you have the same query in more than one place? Do you ever change that query? If so, why not learn how to stick it into a cfc and call that so you only have to change it in one place (if you don't have more than one copy of a query or you never ever change your queries, even this isn't necessary).
Each step into OO land is designed to solve a specific problem. While it is nice to try to "get" OO, it is sometimes better to write and then refactor (get it working, then get it better).
And the fact is that web applications don't last 54 ms - they last years and years of having to maintain them. That is why writing maintainable code is a good idea. OO (when done right) just makes it easier to maintain your code (you're certainly not going to add all the overhead for performance purposes!).
Best Wishes,
Peter
Posted By Peter Bell / Posted on 07/13/2006 at 8:14 AM
Many CF'ers ask "Why OO?" I think Peter Bell's blog entry <a href="http://www.pbell.com/index.cfm/2006/6/26/Maintenance-and-Reuse-One-Out-of-Two-Aint-Bad">Maintenance and Reuse? One Out of Two Aint Bad!</a> addresses it best: OO facilitates maintenance. Particularly with regards to programming within the problem domain of your application, be it logistics, accounting or commerce. And reuse of your own objects is usually a serendipituous, rather than planned (think premature optimization), outcome.
In my experience, this type of reuse I describe above is usually "in the small". That is, you might reuse one object, or even a service that provides APIs around several, but probably not entire an entire problem domain's worth of objects. This reuse springs from a better understanding of your respective problem domain over time. Furthermore, taking an OO approach faciltates a problem domain understanding, and ultimately reuse, more effectively than a procedural one. But OO is not without its own problems. So I think frameworks then are an attempt to apply reuse "in the large" to one or more of these problems (i.e. problem domains), both OO related and otherwise.
Frameworks provide a toolset to solve problems many applications face, albeit generic problems - some of them very OO specific! That being said then, the hazard is using a framework, but not understanding why what a framework does solves a problem.
For instance, with regards to OO, if you have never struggled with resolving object dependencies then you will not appreciate Coldspring (yes I know it does other things as well). But if you build an application that has two or more service layers that talk to each other than you will understand the problem Coldspring solves. And, why it solves it well.
A non OO-specific example is securing an application. Fusebox (a procedural framework - yes it can do OO) and Mach-II (an OO framework) both are tooled to facilitate security without needing to touch a functionality's code (i.e. fuseactions and events respectively). However, until you reach a point where you need to protect many different functionalities centrally, you will not appreciate how it solves this problem.
So at the end of the day, for me at least, OO is about maintenance. Frameworks are about reuse for solving certain problems. And the blog entry is correct in saying there is no right way, or wrong way for that matter, but to truly make progress you must engage in making your own mistakes in order to understand what problems OO presents and the tools out there to solve them more easily.
Posted By Matthew Lesko / Posted on 07/13/2006 at 8:25 AM
Don't worry, I had the SAME exact conceptual issue with first trying to apply OO to cf/web-based apps. This was after 4yrs of comp. sci c++ on unix and some C# stuff, so it wasn't like I was unfamiliar to OO, I just couldn't understand how it would apply to environment where each request was like a completely new execution of your program.
The truth is that, properly implemented, your OO model lives longer than a single request. It will stay in memory, thus an instance of an object is used by multiple requests simultaneously. In some situations, an object may live one request, in another - it lives the entire life of the application, and yet another scenario is that an object's lifespan is tied to a user's session.
Posted By Dave Ross / Posted on 07/13/2006 at 8:47 AM