CFArgument: Object Oriented Programming

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.

Peter Bell
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.

Brian Rinaldi
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!

Peter Bell
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?!

Brian Rinaldi
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.

See, I can be as verbose as you!

Peter Bell
Congratulations!

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.

Brian Rinaldi
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.

Peter Bell
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.

Brian Rinaldi
If the contest was verbosity, you win hands down.

Peter Bell
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?!

Brian Rinaldi
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.

Peter Bell
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.

Brian Rinaldi
Sadly for you I received over 300 Electoral ColdFusion votes.

Peter Bell
Yeah, yeah - show me the hanging chads . . .

I think in order to have a true discussion on this subject, some parameters must be set. To just say OO Programing and CF is a good thing or a bad thing without talking about the different types of projects and processes doesn't do it justice. If you work on very quick, turn key solution to put something online for a one time marketing or survey campaign you probably would not have the same considerations as an architect concerned with supporting a software product throughout it's lifeline. The challenges for these two scenarios and the many others out there are very different and deserve careful consideration on what type of technology and architecture will be used. Until we look at these different scenarios, then this type of going back and forth will go on indefinately.
And as much as I enjoy reading and following them because it does provoke thoughts in our community we need to be careful not to confuse those folks that are reading our blogs looking for how to better themselves and their projects. Now I ask you, for the two scenarios above, what are your thoughts??? Let the discussion resume... (Mortal Kombat voice..)FIGHT!

Cheers..

Fun chat. :) Couple of points I didn't see you guys really cover.

1) Encapsulation isn't uniquely OO ... as a matter of fact, it's not even part of what makes a language OO per se... What makes a language OO is classes, inheritance and polymorphism. Classes are an advanced *type* of encapsulation, although inheritance and polymorphism are merely "tricks" made possible by them.

If you just want encapsulation, you can easily achieve that with custom tags, even to the extent of "business objects" if that's what you want. The only thing custom tags don't inherently give you are inheritance and polymorphism.

2) "Anemic domain models" are an example of the use of OO code to create badly encapsulated business objects which typically fail to leverage the advantages of OO in addition to carrying its complexities. An application built with an anemic domain model generally could have been created more easily using a procedural approach.

And although I don't consider it an indictment of OO programming, they've become popular in the ColdFusion community I think in part because they've been common in some Java circles and also because the mode of thinking that creates them (a procedural mode of thinking) is easy to fall into. http://en.wikipedia.org/wiki/Anemic_Domain_Model

3) If you lay the right groundwork, an OO toolset can actually be *less* work up-front than a procedural approach. I see the same commentary most of the time when people talk about OO programming, that it requires a larger up-front investment to get the project created as the trade for being easier to maintain.

I don't believe that's always the case. In fact in my case I would say that it's usually not the case, it's usually faster and easier for me to create an OO app than to create a procedural one.

Part of the reason why I'm able to easily take very powerful, Google-esque, implicit and multilingual and/or keyword searching from one app to the next is because the OO nature of the DataFaucet ORM makes creating those kinds of search tools very easy... In fact, it's one line of code, whereas it's something like 60+ lines of some *VERY* complicated code if I were to try and replicate that same thing without the OO groundwork. So where's the up-front cost in that scenario? One line of self-documenting OO code, or 60+ lines of extremely complicated procedural code?

@Brian - re the last comment about under-architecting an application... One of the things that's stuck with me over the years from a conversation I had with my dad when I was in my mid-teens... A phrase he said was relatively common in the programming industry at the time "inside of every small program is a big program trying to get out".

@Brian,

I agree with you about one off applications gaining life of their own and later becoming enhanced and gaining a longer lifeline requiring greater architectural organization. I've seen these many times become products and fall victim to "organic growth". But that's a side effect of lack of vision or poor planning. And these scenarios do deserve a good discussion as well.

One sad reality is that nearly every OO presentation and especially the books on OO Design Patterns tend to pick poorly written programs and show how design patterns come to the rescue. You would think knowing design patterns is the key to Uber Software Engineering! LOL They are truly good things to know but one basic thread in all the books is a large development team. How about a debate on small business apps?

The thing that annoys me about coldfusion going oop is that back in the good/v.bad old days of cf5 the idea was (which has been lost along the way) that it was a tag based language which was quick to learn and use which it is. Why did this change? Really because cf coders got ribbed by their java coding friends saying that it wasn't a proper language and it was tagged based. So that is when the rot set in for me because cf is now java. So if you want to learn oop just learn java.

@Trev, there are advantages to tags and there are advantages to OO. Sadly people don't figure out how to make the two work together so we who have ColdFusion can get the better of both. Flex, dotNet, and other languages mix OO with tags. Seems like more CF developers could figure out the great advantage to doing some objects with tags and not abandoning the great benefit of tags. (We do both in COOP framework and it is awesome!)

Yes you are right in your comments John, my point is though 5+ years on from allaire cf5, coldfusion has gone from being simple to being a lot more difficult for new coders. Things should have got easier not harder!

@Trev - I think that depends to some extent on what kind of OO frameworks you're choosing to work with. I've not worked with LightWire much, but I suspect it's simpler than ColdSpring (it looks simpler to me anyway).

Or for that matter check out the recent presentation recording for DataFaucet on ColdFusionMeetup.com - particularly after the addition of the recent cfproperties features. Here's a blog article about that as well: http://datafaucet.riaforge.org/blog/index.cfm/2008/10/14/BestOfBothWorlds

To my mind, the property-driven record objects are quite a bit simpler than writing your own cfquery tags, figuring out where to put them, etc.

I'm tired of non-observable OOP claims of reuse and reduced copy-and-paste. I want to see the best procedural pitted against the best OO for a realistic sample application and actually see the alleged OO benefits with my own eyes. Some just compare good OOP code to bad procedural, and claim a strawman victory. Enough! Show me the flippen code!

Further, OOP seems to help a little bit for "internal" abstractions such as GUI's and reporting frameworks. However, it's often poor at domain abstraction, such as modeling invoices, customers, products, employees, etc. I'd suggest limiting it to internal abstractions where it does better.

@Tom - I completely agree with your need for some real proof of the benefits of OOP. The same goes for canned frameworks in general. I don't have a problem with people saying something like "I prefer to use OOP in CF because it fits the way I think while programming better than procedural approaches." That's fine. But I do have a problem with comments like "OOP is just more maintainable". Ok. Prove it. Based on what? For that matter, what do you mean by maintainable?

I guess the proof issue is going to be a problem as long as we have small teams building large projects. You just don't have enough volume to measure.

If some rocket scientist can figure out a way for us to collectively measure our projects, maybe then we'd have some real answers.