CFArgument: Object Oriented Programming
CFArgument: Object Oriented Programming
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
Peter Bell and I continue our ongoing CFArgument series, this time debating the merits of using object oriented development in ColdFusion (see prior debates about DAO's and IBO's). We also talk a lot of smack as the debate heats up but in the end a poll found that 68 percent of readers think I am focused on the issues while 57 percent think Peter spent more time on negative attacks.
A lot of fuss is made in the blogosphere about Object Oriented programming in CF. I'd like to argue that it's not actually all that important.
Object oriented programming has become the dominant paradigm in application development spanning multiple languages. ColdFusion developers ignore that trend at their own peril.
You giving up already?...woohoo I win!
Hey, it isn't timed chess, give me a sec! Trying to put me off my game...think you can trash talk me out of the zone...I don't think so!
It is important that when you look at the right tools for the job you focus not on what is cool or what is popular, but on what will allow you to build the best application in the least time - where the definition of "best" is determined by your clients non-functional requirements. Given the kind of apps we're often building in ColdFusion, there are plenty of projects where the overhead of building an OO app doesn't provide the best return on investment.
You down? You Out? You gonna admit defeat yet?!
I wouldn't sell object oriented development as the fastest solution to the problem but the investment in time pays off. First, you have the maintainability issue, which, because object oriented applications encapsulate complex logic and dependencies, the time spent often pays dividends in maintenance. Second you have the reusability issue, whereby object oriented development tends to reduce repetition - no more copy/paste programming - which means you also don't repeat your errors. Finally, you have interaction with languages like Java or Flex which generally assume you are using an OO model for development.
I think this is a good example of how OO can get oversold. Whether the investment in writing a more maintainable app pays off depends on how complex the application is, how much you *need* to maintain it, and how much extra work it was to create an OO app in the first place. As for reusability, to me it is a complete red herring. OO apps aren't any more reusable than procedural ones. In fact, I've probably had more luck in reusing custom tags than in reusing rich business objects - the domain model required by different clients is usually too different for easy reuse. As for interaction with languages like Java and Flex, you don't need to write OO code to be able to interface with either of them.
Obviously there is no exact estimate as to how much time you will save (if any) in maintenance, but you haven't actually denied that they are easier to maintain. Also, reusability isn't necessarily about reusing across applications but also about code reuse within an application. Since responsibility is tightly encapsulated, you won't find yourself copy/pasting the same set of code across an application, which can often lead to a mess should that code need to be updated or revised. Lastly, you don't *have to* use OO to work with Flex, for instance, but then you negate many of the benefits of both building in Flex and of the ColdFusion/Flex integration (i.e. whereby CFC instances are translated to ActionScript VO's). Nobody is saying you can't achieve many of the same ends using procedural programming but it helps to use a programming paradigm that is designed with these ends in mind.
I just checked the latest tracking poll and I have a commanding lead.
Dude, you're worse off than McCain, so I think you're looking for the sympathy vote right now.
I certainly don't deny that well architected OO apps are easier to maintain - especially as they grow (although badly written ones can be dogs to maintain, but I don't think that's a fair argument against OO). There is a reason that all of the apps I build are Object Oriented and it's for maintainability as the complexity of the app grows. I also love that by following a few simple architectural guidelines I know exactly where to look for every piece of functionality and I never have to change the same code in multiple places. However, it is important to understand the costs of building an OO app and to do the math to see whether it makes sense for a given project.
Even if you are an experienced OO developer, it usually takes longer to build an OO app. If you or any of your team does not have experience in building OO apps, the cost in terms of learning curve can be huge and I know of many projects that have failed when an inexperienced team decided to try to build a mission critical app on a tight timeframe using an approach (OO) that they weren't experienced in.
In short, I do believe that for the right teams and the right projects, OO apps are more maintainable and a great choice. However, I think it is important that teams don't underestimate the cost of building their first OO app and that they make sure that there will be a return from what we both agree with be the greater initial investment required to build the app using OO principles.
If the contest was verbosity, you win hands down.
And a quote from Brian himself speaking about me and the CF_Argument "...you win hands down". What more do you need to hear folks?!
Well, you do make a number of good points, and I often think OO development is oversold (especially with frameworks). I have seen too many people jump in to OO development with MVC framework X and ORM Y and dependency injection/AOP framework Z and then are surprised that it isn't easy. I did that a bit myself when I was learning. Even now, having done it for a couple years at least, it isn't easy...maybe it never is. However, it seems we both agree, that in general the benefits outweigh the drawbacks, especially once you are comfortable. Nonetheless, it is good to understand the commitment you are making beforehand.
I agree that for *some* projects the benefits outweigh the drawbacks, but I think it's important not to generalize as there are still some apps where a quick and dirty procedural approach might actually provide better value to the client. On the other hand, I do believe that *learning* OO programming is essential for anyone to consider themselves a professional programmer. I don't think that every project benefits from an OO approach, but I don't think you can effectively make the judgement call on which projects should be OO unless you're comfortable and experienced at building OO apps.
Sadly for you I received over 300 Electoral ColdFusion votes.
Yeah, yeah - show me the hanging chads . . .
Published at DZone with permission of Brian Rinaldi , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.