A few weeks ago I received a message forwarded onto me from someone in the Triangle Area ColdFusion User Group about frameworks and object oriented programming. The person who forwarded the message on to me asked for my input, which I figured I would give here on the Alagad blog.
TACFUG,
I am having some trouble at my new job explaining why Frameworks, MVC and OOP style application development in ColdFusion is preferable to development without them. People here are interested but don’t really understand why these are such a great thing.
The counter argument I am hearing are things like: OOP is a bunch of extra work and that these things will take the rapid out of our rapid application development. Frameworks make things too complicated and difficult to troubleshoot and hurt application performance in a major way. MVC doesn’t make sense in a web application.
I am asking for the ColdFusion community to help me clarify the benefits of OO (or tell me that OO is stupid and I should forget it).
Do any of you know of any good breeze/connect presentations or articles that could help me explain the costs and benefits of MVC-FW-OOP?
Thanks for your responses!
~David
David, asks one very important question. Specifically, why is Object Oriented Programming a good thing?
He goes on to provide a few counter arguments (amongst many more that have gone unsaid). I’ll pick these two to highlight:
- It’s Harder
- It’s Complicated and Creates More Work
The question and counter arguments can not be answered categorically. This is because the exact properties that some people hate, other people love.
Two of the answers as to why I use it would, in direct contrast, be:
- It’s Easier
- It’s Less Complicated and Saves Me Work
“What?” you say. “How can this be true?!” I’m glad you asked.
Object Oriented Programming requires a shift in thought from procedural programming. Actually, that’s the only thing it requires (besides the ability to create classes in your programming language). The problem is that this change in thought process is hard.
Rather than focusing on the goals of a process, Object Oriented Programmers focus more on what a particular object, or component of the system, is responsible for. There are thousands of examples of this on the web, but I’ll endeavor to create my own here:
Let’s say we have a problem where a website user needs to be able to send an email which uses a recipient-specific template and is composed of relevant data.
The procedural mindset says we have a specific set of steps we need to proceed through to accomplish the goal once the user has clicked or otherwise initiated the process:
- Figure out who is sending the message
- Figure out who is getting the message
- Figure out what template to use
- Figure out what data to use
- Compose email message
- Send email message
Of course, each of these steps is really broken down into several smaller steps in code. Even with ColdFusion it’d be hard to make this example in 6 real lines of code.
Meanwhile, the object oriented mind will use techniques it has developed through time and experience to sift out various groups of related functionality not just from this particular goal, but from the entire project in general.
For example, we might see that sending an email is something we do in several places on the site. We might also note that we’re using the same templates and data in several places on the site.
If we’re doing the same thing over and over, why rewrite that logic each time? In ColdFusion we have several well known techniques available that enable us to reuse application logic. Off the top of my head we have cfincludes, custom tags, the ability to create function libraries, not to mention ColdFusion Components.
If I were not using CFCs, I might make a custom tag responsible for creating and sending a templated email email. Perhaps the programmer would pass a query to it and the email address for the recipient. I can then reuse that custom-tag anywhere on my site that I wish. The component becomes responsible for getting the job done while the programmer is not concerned with how it is done (or, should I say, the procedure followed to get the job done). We encapsulate a complex action into one custom tag.
The problem with custom tags is that we only have one entry point. We call the tag and provide arguments. We can’t easily change how the tag does its job without changing the tag itself.
Let it suffice to say that I, as an experienced object oriented programmer, understand that if I wrap my functionality up into a CFC that I can more easily modify how it functions while, at the same time, lowering the risk that if I make changes I will break code that uses this component. So long as my input and output remain the same I can change how code does its job to my hearts content.
But, beyond that, objects have many other interesting properties that can be pontificated about for many, many, hours. In the end, I believe that objects make my code simpler. Mainly because I can focus a given object on doing one thing and one thing well. It’s simpler to write one component than an entire system.
Once my CFC is written it is nice, clean, and concise to use, and could care less how it works.
<cfset TemplatedMessage.send(reportData, "skippy@dinglehoffer.com") />
What’s simpler than that?
Like object oriented programming, frameworks makes things simpler. Frankly, the problem of how to handle website requests and responses has been solved. It has been for years. Why reinvent the wheel for each project?
Beyond traditional web frameworks there are also a plethora of other frameworks designed to make your live easier: configuration frameworks, unit testing frameworks, data persistence frameworks, validation frameworks, and much, much, much, more. Again, these things are already done. They work. If I’m already working with CFCs it’s essentially child’s play to pick these things up and run with them too. This saves me work, it saves me time, and it saves me and my clients money.
To be honest, I’ve only scratched the surface of why I think Object Oriented Programming is easier than procedural programming. I could ramble on for quite some time. The fact of the matter is that it’s easy because I think like this every day. Meanwhile, for the people who argue against it, Object Oriented Programming is hard because they don’t think that way.
At the risk of perplexing people, I’ll say that I find procedural programming hard. I don’t like to do it. It’s too unstructured and hard to follow and debug. It’s hard to do any form of meaningful quality assurance. It’s hard to work with a team in on procedural programs. I just don’t see the advantage and don’t understand why people promote it so enthusiastically.
DougHughes.net 
Comments on: "Procedural Programming is Hard!" (21)
What they need is something like COOP. (Shameless promotion… heh) What if the designers could be procedural and the developers could be object oriented for request processing? (After all… isn’t HTML procedural anyhow?)
LikeLike
I am about ready to take the plunge and try doing a simple oop site. The one thing in your argument doesn’t make clear is how the custom tag is different than a cfc. You say that once the cfc is written you can always access it the same way and still change what happens in the background.
How is this different than a custom tag that takes some specific data and outputs a specific result? The code that calls it never has to change even if you redo the internals of the tag.
LikeLike
Essentially, the major difference is that CFCs and objects are stateful and have multiple entry points.
Thus, you can model real world objects. IE: a person can have properties such as height, weight, etc. It also do things (the multiple entry points) like run, jump, sing, whatever.
You can’t do that with CFCs. Then, there’s all the other tenets of OOP that tags can’t do.
Big question to which I give an inadequate answer.
LikeLike
Well there are things CFCs can do that Custom Tags cannot… and things that Custom Tags can do that CFCs cannot. You summarized half of the reality in your last post.
Now let’s look at Custom Tags.
1. They can store content generated between start and end tags.
2. They can execute code on start and end.
3. They can validate there is an end call at the start.
4. They can loop wrapped code.
5. They can choose to hide generated code.
6. They can nest and share data structure in a different way than CFCs would. (Which being unique of course provides unique abilities.)
7. They can be stored outside the web root and called without any class paths.
I am not saying these are always strengths compared to CFCs. We use CFCs and Custom tags with our technology. What we discovered
Here is an old post from Fort’s site.
http://www.forta.com/blog/index.cfm?mode=e&entry=1050
Therefore on a markup page custom tags are the tool of choice. On a logic/processing page the tool of choice would be CFCs. In COOP we have taken this concept to a level that Sean C. looking at an early version gave us a very positive review.
My question for you would be how can we appropriately mix COOP with Model glue? Fusebox is easy to me. Are you up for taking a look at it?
LikeLike
John, you miss the point. CFCs are stateful, tags are not. I don’t know anything about coop, but based on your description I’m not interested in it. HTML is not programming, much less procedural. What Ben says is not law. Etc, Etc.
Move on now, nothing to see here.
LikeLike
I reckon people think OO is hard because the environment is hard. If you’re just banging out short lifespan procedural code – well, lucky you. Many of us are dealing with a fair proportion of the top 10 all-time hard problems in system design – multi-tier client/server, concurrency, clustering etc. That’s a bear of an environment to learn “hello world” in, let alone a whole paradigm.
Add to that the fact that our tools all, to some degree, adulterate OO principles for various historical and pragmatic reasons, and it’s like learning to fly while blindfolded in a burning 747.
My recommendation? Download a copy of Smalltalk (or Lisp, or Scheme, or even Java), get a good book, forget about databases, web clients, session management and all the other crap, and just learn OO.
LikeLike
Hi Doug,
While I’m obviously a fan of OO, what I think you’re missing out is the cost of the learning curve – not just of OO, but also of every framework that you add. Let’s say I’m a designer and I need to learn just enough CF to be able to have a single form save data to a database. Would I *REALLY* be better off learning MG, Transfer, CS and OO along with design patterns like Singleton, DAO and the like just to get that page live?
the other point is that I’d say OO IS more work – for smaller projects. If someone needed me to write a green field single page form app, I may just stick the logic at the top of the cfm page. If they want me to write something that sends one simple email in one case and there is little likelihood of it changing, I’ll probably drop a cfmail into the page. If they want me to build something non-trivial, obviously I’d take an OO approach because it’ll save me time by the time I hit the third or fourth object.
However for someone with no OO experience who couldn’t amortize the cost of learning over n-projects or was on a tight deadline, I might suggest a procedural approach using Fusebox to bring some order to the chaos and recommend they learn OO in their spare time so they’ll be ready for the next project or refactoring this one next time around.
LikeLike
Peter,
Thanks for your input! The point about the designer and the single page needs are great ones. In fact if the level of needs are simple using something like COOP would name the designers life much easier using COOP.
The point here isn’t our framework… the point is that custom tags actually speed integration and ease of use for designers if we developers will start working with them rather than just training them to work with us. It has become apparent that we are pretty arrogant that rather than building tools that put the designer and the developer into common work flows we are forcing the developers to bend to us. It honestly seems like it’s more about a control issue than about learning to use our talents to work together. (That was the focus of my talk at Frameworks Conference last Feb.) If we learn to work together the end users and the site owners all should be happier also.
Custom tags clearly bring something to the table that CFCs cannot do in the area of markup. (And Doug… you are right. Ben’s opinion isn’t the law. But in this case he does see something many of the gurus need to look at again. Smile and take another look when you get a chance.)
LikeLike
As always it’s about the right tool for the job. One of the strengths of ColdFusion right now is that you have the frameworks when you need them, but you can also crank out a small procedural .cfm file when needed. Personally, my goal with everything is that it balance ease of coding with ease of maintenance. With the small things, I can always refactor it later if the project grows.
LikeLike
[Quote]
“At the risk of perplexing people, I’ll say that I find procedural programming hard. I don’t like to do it. It’s too unstructured and hard to follow and debug. It’s hard to do any form of meaningful quality assurance. It’s hard to work with a team in on procedural programs. I just don’t see the advantage and don’t understand why people promote it so enthusiastically.
[EndQuote]
Just a few random thoughts..
Much of the ColdFusion code I’ve seen is very unstructured, but that doesn’t make it procedural. Unstructured NEQ Procedural.
If it is hard to debug or do quality assurance, then you have architecture problems. This is independent of using a procedural or OO approach to development.
In my experience, the initial development using OO takes longer. I believe the real savings are in maintenance. That might be a hard sell for a ‘one-off’ project. As developers, we know there is no such thing as a one-off project and changes always come. Clients tend not to realize that, though.
LikeLike
“In my experience, the initial development using OO takes longer. I believe the real savings are in maintenance.”
I didn’t say as much in the article, but this is really the end game here and the real selling point of OO. Yes, it takes more up front time, but only because it required more analysis, really. Then frameworks help accelerates the process too (once you’re comfortable with it).
LikeLike
Silly thing, really. I agree with most of what was said above. What bugs me is…why the heck can’t we use CFC’s as Custom Tags?
Food for thought…totally OT for the post, of course…
LikeLike
I don’t understand what you’re getting at…
Do you mean that yo want to be able to call CFC methods in a tag format?
LikeLike
No. What I mean is I want to implement a CFC and call it as a custom tag, a la .NET and web controls. The idea being that Custom Tags can become a whole lot of “procedural” sphaghetti, while an OO implementation of Custom Tags could be very useful.
LikeLike
I don’t have the .NET comparison in my skill set, so perhaps that is why I’m not grokking.
I don’t understand the distinction between your words “call it as a custom tag” are my words “Call CFC Methods in a tag format.”
I generally view custom tags as a single procedure. They encapsulate functionality. CFCs encapsulate both functionality and data. Either one can contain procedural, OO, or spaghetti code.
LikeLike
I have no idea what you are talking about either. Why would you EVER wrap a custom tag in a CFC? It seems to me that you could put that same code directly in a CFC if using the CFC was your use case. That would help… could you give us a use case where there as EVER an advantage to wrapping a custom tag in a CFC rather than moving the code to a CFC?
There are presentation/markup advantages to custom tags. Nearly everything else goes best in a CFC. CFCs are stateful, they inherit… and they work for unit testing. There are reasons to use a CFC inside a Custom tag but to go the other way around is something I have never seen an advantage to YET. (Wouldn’t be the first time someone taught me something… so seriously, please do.)
LikeLike
I wasn’t suggesting “wrapping” a custom tag in a CFC. I was suggesting being able to USE a CFC as if it were a custom tag. By defining an “interface” that a Tag CFC would be required to implement (yes, I know CF doesn’t support interfaces), eg: a render method, you would then be able to have UI CFC’s.
You would then be able to instantiate, set properties, and call the render method via a “tag” implementation, a la:
Realistically, a Custom Tag could do anything a CFC would be doing in that sense. It’s the idea of modelling controls (eg: tags) as Objects instead of simply as procedural “pages”. I see no reason why a custom tag (“control”) shouldn’t be stateful if it needs to be.
Anyway, I honestly haven’t been doing much CF recently, and I’m trying to articulate how I would see this being useful…I’ll have to blog about it from my end instead of hijacking the comments here, though.
LikeLike
Interfaces were added in CF8?
Maybe you want to take a look at cfinvoke? Conceptually, it is to CFCs as cfmodule is to custom tags.
That said, I see no problem with building a CFC for display purposes and making use of the stateful nature of a CFC if needed.
LikeLike
Acutally, this might simplify: I think what I’m trying (woefully inadequately as the case may be) is: CFX tags written in ColdFusion (as opposed to C++ or Java) as CFC’s, callable as tags.
http://livedocs.adobe.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/js/html/wwhelp.htm?href=00001071.htm
LikeLike
CFX is supposed to be a way to extend the language to do things that CF can’t already do. Building a CFX tag in CFML would be overkill, even if doable. What benefit would this offer?
LikeLike
It really annoyes me when people say that code reuse is non existant in procedural programming. Code reuse is EXACTLY what libraries are made for. When using any procedure from a library, you also , “dont care how it works”, you also, “just use it”. In my opinion, procedural programming is better. Its really irritating that people like Microsoft say, “OOP hallelujah” and all you sheep jump up and throw your arms in the air. Pathetic. All MS and SUN and co want to do is sell ideas. Lucky for them there are lots of gullablle people like you lot. Killing off procedural programming is killing of RAD. Its a bad move and after a while the procedural programming ideology will return, before the next cycle begins and new lambs run forwrd to throw their arms in the air.
LikeLike