Object Oriented Programming And ColdFusion - What's The Point?

I don't see pure OO as a goal or a target. It is one way of looking at an application that may help you to do a better job of putting behavior alongside your data (which typically is good from an encapsulation and information hiding perspective).

Some of the stuff like domain objects not being able to persist themselves, I just flat out disagree with. I think it's great you took the course, and Hal is incredibly smart and knowledgeable. I'd just look at all the material you covered from a programming, first principles perspective (will this create a more maintainable app, etc) and then ask yourself which of the principles will make your app better and why.

It's important to understand we're not in the business of modeling real world objects - that is not what OOP is about. However, we may pretend that we are doing that to help us with designing parts of the domain model.

http://www.pbell.com/index.cfm/2008/10/27/I-Dont-Care-What-An-Object-Is

At the risk of sounding quite naive here, what are some examples of applications that have behavior (and thus are more suited for OO)? The majority of web sites I visit are simply there to show me some data. Online banking, email, shopping, news, blogs, forums, facebook, ... are all just UIs for different kinds of data.

I could possibly see how video games or virtual reality UIs begin to get into behaviors. In a lot of OO intro materials you get example of a Dog object that has a bark method or a Car object that has a start method. That's good for getting the concept, but unless you are building a video game, you probably don't need a dog that barks in your application.

What are some common behaviors I would see in non-video game apps?

@Ben, A few comments!

> one of the big payoffs of it is that we can reuse our code in different systems within in the same domain

I completely disagree. Just because you are modeling the same class of real world object in two systems it is quite likely that they'll actually have different behaviors and properties as the two different systems will often implement different subsets of possible real world behaviors or will even use different conceptual approaches to the same real world objects. In my experience, reuse of domain objects between distinct projects is a fairly rare and limited situation.

> I think you've told me that you have like 4 physical CFCs in your SystemsForge stuff right? So, for you, the concept of reusing CFCs in different applications within a single domain is laughable as a goal

Well, actually I DI reuse objects between projects (notwithstanding what I've said above, because I have a lot of fexibility to direct the implementation details of my projects, I actually can quite frequently reuse domain objects between projects with fairly modest changes to their behavior, relationships and properties) - I just describe the objects using XML rather than coding them using CFC's.

> What I need to do now is take the principles that I have learned in the class and see how I can apply them to my software development whether in whole or (most likely) in part.

+1!

@Matt, I find my objects start getting behavior when the data isn't quite enough to describe everything. It starts simply when I need a DisplayPrice for my Product. It might encapsulate simple logic (If DiscountPrice > 0, return DiscountPrice, else return BasePrice). In my cart, the ItemTotalPrice is probably ItemUnitPrice * ItemQuantity (or even Product.UnitPrice * ItemQuantity depending on when product price updates affect the items in the cart). Those are the simplest possible behaviours as they're really just encapsulating the business logic required to get a property that doesn;t exist in the db. Same thing with a User.getAge() that'll calculate the age (which is not persisted) from the dob (which is).

Other more obviously behavioural behaviors would be things like Newsletter.Publish() or even site.Publish(). Project.generate(). page.display(). These are examples of methods I have in my apps.

You could also have things like message.send() and I find it perfectly acceptable to have things like NewProduct.validate() or NewProduct.save().

You could have a User.upgrade() method which would validate the request, change their status and persist their new status in the db (some composition would probably be involved - you probably wouldn't want to be writing SQL in your domain objects directly).

The common thread is that we're putting behavior and properties into one place to hide as much information as possible and to minimize coupling, so if I decide to change how I calculate my Product.displayPrice() logic, I change it in the Product object and because all of my screens just call that one method, I don't have to worry about changing the code in other places, hence making it easier to maintain my app.

@Matt

. . . continued . . .

I never ask myself whether a real world page will know how to display itself or whether a real world newsletter will know how to publish itself. Why would I care? Why would that be important to me? What value does asking that question provide me with? Rather I ask whether the behavior is cohesive with the objects other behaviors, whether the class file is getting too big, whether it'll help to make the app easier to maintain., whether it'd be easier to test if I delegated the behavior to a composed object, whether adding a composed object might cause major performance problems if there were arrays of the object being displayed in my ColdFusion apps. Those are the kind of things I'm thinking about and I'll often trade one heuristic off against another. But I never worry about what a real world object would do as I don't usually find that to be relevant to the process of creating maintainable apps.

To each their own, however.

@Ben, I hear what you're saying, but my argument has for a long time been that in practice OO provides for greater maintainability but NOT for greater reuse and this seems to be a pretty common opinion. I wrote something about this a while ago:

http://www.pbell.com/index.cfm/2006/6/26/Maintenance-and-Reuse-One-Out-of-Two-Aint-Bad

Of course, in the domain of programming there are objects you'll be able to reuse. As you pointed out an XML document or a float will probably be the same across the majority of applications. So are generic DAO's and Service classes and IBO's which is how I get a good level of reuse of my base framework classes across web applications, because they are the same domain and I have control of the business rules I choose to implement within that domain of web applications. However, in my experience, the behaviors, properties and sometimes even the relationships between domain objects in rich OO apps are seldom reusable as is between applications.

Think of it this way. You could create a standard e-comm app and sell it to four people. procedural or OO, you'd be reusing code which is generally a good thing. But now try going to Amazon, Chevvy, Lenovo and a PriceWaterhouseCoopers. Ask each one what a product is in their domain and see how easily you'll be able to reuse your domain objects.

Typically the benefit of OO programming comes as the domain model becomes richer, and in my experience of building hundreds of web projects, the richer the clients domain model is, the more likely it is to be full of business rules that are unique to the way that they see the world and therefore the less likely they are to be reusable across apps.

There is no question that for simpler domain models you can reuse code. We often reuse page, user, newsletter, product, cart and a bunch of other items (we usually have to tweak a few properties as each client has slightly different needs and believe me - the solution is NOT to have a set of uber objects with every possible property and behavior - been there, done that, got the t-shirt). However, the richer the domain model, the more likely it is to be specific to the world view of that particular customer and the less likely it is that you'll be able to reuse the code.

@Ben,

I think another important point to make here is that not only are we not modeling idealized real world objects because of technical considerations (we need to model the behavior required to implement the essential user stories - not the whole universe of possible behavior), but in addition to that, our clients actually have their OWN conceptual model of what a product is or what a customer is or what another object is, and those conceptual models often vary widely between businesses. In some businesses a contact is a type of person that may or may not be associated to a company. In others, a company simply has a ContactName property. You can model the true real world relationship however you want, but what really matters is the conceptual model that the client has underlying their domain objects and often the same domain objects are thought about differently in different companies. That is what really kills the general re-usability - we're not modeling the same objects and the different clients conceptions of those objects vary - stopping us from reusing the same objects between those clients.

So when you say behaviors, I am not sure I understand. Take OOPhoto. Let's say you had functionality to:
- order in album, rank (favorite), print, resize, rotate, write caption, move, copy, make album cover, write on top of picture, tag, declare face-recognition, download, share, blog, embed, zoom, undo, next/back, replace, delete.

These are "some" of the things you can do in Picasa, for example.

So are you saying, none of these are behaviors? Wouldn't a picture know how to rotate itself? How to write a caption for itself? How to validate that the caption is acceptable?

OOP Does make alot of sense to use if you are coming from the systems analysis and design approach rather than just sit down and start coding.
OOP has come intuatively from UML.
With most large companies the senarios are planned out with use case diagrams and use case class diagrams. so from these you create your classes which are your objects.
so from that angle it is the easiest way to go about it.
if you are making a basic application then there is not really much need, but once you start to think in OOP they you just start to use it weather you need to or not.
Generally it just makes it easier to add extra functionality and for future developers to understand your code.

I just want to make sure that the anemic data driven apps that we are so often confronting are appropriate for OOP. There is a lot of overhead for object-relational mapping (even though CF9 will supposedly have it built in). And, to be frank, OOP breaks some of ColdFusion's Rapid Application Development tools as we know.

I'd like to see an honest discussion about the "it depends". I've seen everything but the "it depends" clarified.

Peter makes sense because he is a pragmatist.

He wants to make the most money, which means completing projects that meet every objective as quickly as possible. While pure theoretical OO is nice, you can spend a whole lot of time preparing for something that is a guaranteed flat result.

Why object-oriented programming? I think the benefits to decomposing your application's functionality into discrete pieces are almost too numerous to list. You can isolate changes to one part of the application, reuse components, unit test one tiny piece at a time, etc, etc.

But object-oriented programming is only one way to chop up your application. We've been inventing and refining ways to do this since the 1970s, when David Parnas introduced modular programming. Paradigms from functional to object-oriented to aspect-oriented have this goal in common.

As others have said, it is not a choice between OOP or nothing. Any way to modularize your code will improve your life and the lives of those maintaining your applications in the future.

@ Matt Williams

I just spent the last three weeks rewriting the core spidering robot for my website, WoW Lemmings. It is a multi-threaded CF app that is composed of two key parts:

- The main object that contains a list of spiders, and has methods that manage the spiders across threads, as they touch URLs, scan data, and update/refresh/delete a database.

- Multiple spiders that derive from a base spider class, which inherit common functionality that all spiders use. Derived spider objects implement an interface that requires them to supply certain methods back to the main object, which are either declared in the base spider or are overridden and implemented in a new and specific way in the derived spider.

The spiders themselves, and the parent object that manages them, all have properties, behaviors, etc. The application as a whole demonstrates common OO fundamentals, such as encapsulation, polymorphism, and inheritance.

This may be a more appropriate "concrete" example of an application as it pertains to OO-development in use within ColdFusion.

I think the struggle procedural CF developers often have with embracing OO is that it causes you to approach the development of an application from an entirely different point of view.

Ben's original quote: "Photos don't know how to do anything. Galleries don't know how to do anything."

I wager that with a bit of rethinking on the part of the developer, it wouldn't be too long before you had the following lines of code in your application:

galleryObject.DisplayPhotos();
galleryObject.DisplayPhotosByGrid(4, 3);

and

photoObject.Display();
photoObject.DisplayThumbnail();

Suddenly, photos and galleries now know how to do something.

As one of the people who sent Ben and email asking "What's the point?", I am happy he wrote this post. I didn't ask "What's the point?" because I think OOP is bad, but I wanted to hear from someone who had put for the effort to learn OOP to see if there is something I am missing, and to evaluate weather I should put forth a similar effort.

I appreciate how David said:

>...it is not a choice between OOP or nothing. Any way
>to modularize your code will improve your life and the lives of those
>maintaining your applications in the future.

I have done a lot of reading into OOP, and it seems like "Maintainability" is usually the primary reason the OOP experts give for implementing their chosen programming paradigm. However, it seems to me that in ColdFusion, OOP really just makes developing things more complicated, and sometimes adds unnecessary processing overhead. Also (as someone that regularly has to hire CF developers), it seems that the majority of CF Developers out there are more comfortable developing in a procedural fashion, and CF developers who actually are comfortable with OOP are almost always comfortable working with well organized procedural code as well. Threfore, it is easier to maintain a staff of people to maintain a CF application if it is procedural.

That is why, while I have implemented some OO-ish principles to my programming style, I continue to program procedurally, and I have not put forth a lot of effort in training my mind on how to turn everything I program into in an object.

I think if you do a good job of identifying the parts of the application that can be modularized with a generic CFC, or Custom Tag, or UDF, and you do a good job of organizing your code (so it doesn't turn in to a pile of spaghetti with 1000 .cfm files all in one folder), then maintainability is not an issue that should decide weather your do OO or Procedural.

The main reason I can see for choosing one programming paradigm over the other really boils down to simple personal preference.

It almost sounds to me like we're discussing two different issues here. Ben and Scott seem to be thinking about OOP as an all-or-nothing thing, and they seem to be asking if they should make *everything* in an application an object.

Many of the people responding, I don't think are answering the question - or even really hearing the question. The question that people are hearing you ask is, "should I use any objects at all ever?" and so of course, they're answering that yes, you should, quite obviously you should.

That's my take on this discussion. Except for Peter, it looks like people are answering a question you didn't ask.

Here's my answer: should you make everything an object all the time without exception? I say no. But on the other hand, you should be intimately familiar with the power of OOP so that you are able to use the best tool for the job at hand. Many of the applications I write are *not* entirely OO, but in almost everything I write, I find that some part of it is best implemented as an object.

A quick example: I'm doing some integration with the google calendar. I get an authorization token from google and then use that token on subsequent reads and writes. This can be implemented procedurally. Procedure A gets an auth token, which the calling program stores in a global variable and passes to proc B and C, which read and write calendar entries.

But if you have that OO tool in your bag, you see this setup as tedious and needlessly complex. Ten years from now when I have to maintain this code, I don't want to have to think about auth tokens. I shouldn't have to remember rules like how long the token is valid.

An OO solution encapsulates the token and the read/write methods, and ten years from now when I have to make a change that tedious detail is hidden from me. Also, if I need to work with two calendars simultaneously, I don't have to juggle auth tokens in global variables. I simply instantiate two objects, and they handle themselves. Finally, when I start working with resource calendars, I'll find that the code is almost exactly the same - but different enough that I would need new procedures if I had implemented it that way - with OO, I can use inheritance and have the resource class make use of the calendar class' auth method.

The bottom line is, this is an incredibly power tool. You don't have to use it all the time, but you should be ready to use it when appropriate.

@Chirsopher,

As I mentioned in my last post I use some "OO-ish" principles in my programming style, and I have developed CFCs to create "objects" for certain parts of applications when I think they are appropriate similar to your google api example, and instantiate the object into a memory scope to maintain it's state and use it's properties and methods to handle events in my application. However, I have always been under the impression that there is a difference between writing objects that can be used by a procedural application and writing applications that are truly "OO".

Are you saying if I use a few objects in a generally procedural application, does that make it Object Oriented? Or is there perhaps a magical ratio of objects to procedures in an application that must be attained before I can call an application OO? =)

Nice discussion guys. This kind of topic would be a great round table discussion, recorded for podcast oh course.

By the way I do lean towards the OO side. Even at times when I seem to be creating more code than I would normally, in the end it comes together better and I do think it makes a more maintainable application. Overall I can't say that I think that I have ever made an application less maintainable by making to OO.

This may not be a good comparison but our admin side of one main portal application is its own entirely different site written using a different framework but we do re-use objects between them when we can. It usually works better if you know about the re-use up front. Some have xml (coldSpring) config files that load them up differently. Yes there are times when the needs are so specific we write completely different cfc's for the same objects.

@Jonny - you said 'OOP Does make alot of sense to use if you are coming from the systems analysis and design approach rather than just sit down and start coding.'

I have to disagree.

Using an Agile approach you may start off with a unit test and an empty cfc, write a few lines of test code then make the test pass with a few lines of code in the cfc.

You may well have a vague grand design sketched out on a whiteboard and have a good use case in front of you for the focused task at hand but I think OO works better using an Agile 'bottom-up' approach rather than a clasic 'top-down' approach.

I have always found my top-down design is completely different by the time I finish the project so tend to not spend as much time on it these days and just develop things, bit by bit

After taking a job that deals with coldfusion, the first thing I did was look into OOP. I have to admit, coming from a PHP and C# background, Coldfusion OOP seems pretty pointless as well. It's ugly and doesnt even seem to be OOP at all.

Just my two cents.

@ Ben

After a few additional years with OOP and being more seasoned with it.. how are you feeling about it now?

As I have been learning then ins and outs of CFML or jQuery everything has been like wow! I cant wait to use this! But with OOP, which I have just begun getting into, I keep questioning its utility in typical web development.

One of the truly profound benefits of designing and implementing an object-oriented system (whether in CF or other languages) is the intimate knowledge you gain of the business and domain you're coding to.

I was involved in a 3 year project involving the consolidation of numerous sites that offered conference registration, publication subscription, lecture viewing, and case study interaction, all of which we broke out into 'activities', which has common functions to all (ie. registerFor(), confirmRegistration(), display(), etc), but that got very specific once a user had drilled into them.

We built the site using FB5.5 (no-xml) and the mvc layout made for a very clear and consistent understanding of how the many parts of the site came together--especially helpful for members of the team not fluent in CF.

Once the objects were in and interacting, I gained much more insight into the business rules that needed to be enforced. It was one thing to read a set of requirements and understand the general idea of the objects...but it was another thing entirely to have them implemented, seeing how they differed in some places, and remained the same in others. I felt like I came out of the project with an intimate knowledge of the domain having never worked in that industry before (oncology, training).

I'd also like to add that it makes for reading/understanding/maintenance of other people's work an order of magnitude easier.

I moved to a new position recently and had the luxury of inheriting someone's ColdBox app, which was extraordinarily relieving. It read like a book. I very quickly understood all of the discrete objects in the system, how they interacted, what their role was, and how the system ran.

I didn't need documentation (is there ever any?) to learn how the system was built and functioned--it made sense from the start. The last time I experienced that...never.

In comparison, I've seen and inherited many a monolithic mess of spaghetti code with includes of includes of includes of includes, with no rhyme or reason, no consistency--and to me they are not only difficult as HELL to read/understand/maintain--but they don't demonstrate to me the developer even had that understanding of the domain...that every change that requested was just 'one hack on top of another' to make things work.

Who wants to be a professional software developer with that mindset?

@Shawn

Would love to just once take on an existing site where I didn't have to stumble down "Include Trail". I once had the pleasure of rewriting a site that had up to 11 deep includes in about 30 different directories with no rational for why they were there or even why the code was in an include. It was frustrating, but at the same time it was a invaluable lesson that inspired me to become a better developer.

In the past, I transiently invoked methods which has really made a difference, for me at least, in terms of a cleaner, more understandable and up-datable application.

Maybe OOP will be something I can appreciate much more once I really start implementing it on some projects.

Not long ago, I interviewed for a job with a company that was one of those 'contracting outfits'...that is, you go to the company because you are without work, and they have a collection of jobs from different companies that they send you on interviews for. It is both a benefit, and can be something of a con that they have extensive tools to help you along, including some level of training (the reason this is a con is because you can do great on interviews and actually get a job, but sometimes you are only loosely qualified for those jobs, and working can be a struggle at that point).

Anyway, one of the training pieces I had for a job was for ColdFusion. The people they were sending me to, the company, was insistent upon hiring an "Object Oriented ColdFusion Developer". During the training for this specific job, they stated that ColdFusion, that is CFML, was not written in an object-oriented way or in a way that was conducive to object-oriented programming. I know that what I am saying may cause some people to become insensed against it, but I am only trying to share an experience and hopefully some insight into this question...the question of "Object Oriented Programming And ColdFusion - What's The Point?"

And to back up the fact that maybe I have enough knowledge to comment, it's not ColdFusion that I would have struggled with. I have had many ColdFusion jobs, training in school, and am certified in ColdFusion 8. (93% on my exam). I know a lot of people don't puch much stock into those exams or certifications, but I still think the percentage range I fell into says I know a little bit at least about the subject...it'd be hard to 'get lucky' and get that high of a score. I was hired specifically for my last job for my ColdFusion experience, and was responsible for training my department to use ColdFusion. I'm not the strongest or the best ColdFusion developer, but I do have a bit of experience with it.

Anyway, back to my original point, the said that CFML was not an object-oriented language, or that it was originally not designed that way. Of course, the purpose of CFC's, I guess, was to bring it more into the object-oriented forefront, but what I have found at various jobs is that different people mean different things when they say "object oriented".

I know we don't want to get into an argument of semantics here, but I think what people mean when they say certain things is a pretty important thing to understand in any discussion. The company that wanted me to understand ColdFusion from an "object-oriented standpoint" didn't have any applications that I could see that were any more 'object-oriented' than my big toe. I have had many companies that I worked for that would ask me if I had an object oriented methodology behind my programming, and then when I would work for them, I would struggle to see any kind of an object oriented set up.

I even worked for a company that had what I thought was a great MVC set-up, but I didn't really see anything that was representative of the things I learned about in school when I took c++ and Java and learned about how Object Oriented Programming worked using those languages.

I'm not picking on ColdFusion...one of the companies that I worked for which asked about the Object Oriented thing developed using php, and I didn't really see too much object orientation going on there either.

I agree totally with @Ben, in response to @Chris and @Shawn, I have worked for companies before that did have a very Object Oriented setup, and their code wasn't always easy to follow...I have seen it implemented in ways which wasn't really terrible easy to follow. I think the implementation is more important when it comes to being able to go into someone else's code and make updates rather than a specific way it is coded...object oriented or otherwise.

I believe it was @Peter who brought up a great example of something that would do well with an object oriented set up, and also the aspect of developing different applications for different companies. There are companies that work on specific websites, but there are also companies that develop different applications, and then sell them to other companies, for example, for inclusion on their websites. I was going to work with a company that was going to do a shopping cart like that. Some other examples include calendars, testing modules, a help desk application, etc. But having the applications developed using an object oriented approach does help with developing an application that can be used by different companies. One of the software applications we bought at one company was a helpdesk application, and it was one of those that was developed by one of those companies that just develops applications in general and then sells them to companies like the one I was working for. Applications like that do well to be developed using an object oriented approach. Sometimes, though, when you are working for a company, and you have one site, it can be quite a challenge to write the whole site using the object oriented approach. Also, as was mentioned, when you start working for a company, and they have a whole site and/or application or set of applications developed, it's hard to go and re-write everything if the original approach was procedural, and it can also be difficult to sneak in object oriented stuff when the whole site/application/whatever was already set up a different way.

I have no preference either way, really. Generally, I just like being able to write code for stuff and it works. I have, probably fortunately and unfortunately, not had much say over the way stuff was developed for most companies where I have worked, for the most part, so I kind of just have to make it work in whatever way it works, usually. So it might be different if I had an actual say, but I don't. If I did, I might could choose either procedural, object oriented, a hybrid, or some other approach, but I just don't have that level of authority or control.

Sadly whenever oop comes up everyone forgets what made cf popular to begin with and what jeremy Allaire`s original goal was.
Whenever anyone new to cf asks for help, oops is usually rammed down their throat and they are told they must use it or their code is crap.
While oop has its place, it is more for the hardcore experienced programmer who is building big projects, multiple projects or working in teams, it is absolutely not required at all, certainly not for the occasional coder or newbie.
The whole beauty of cf is it's simplicity and easiness to learn and understand the basics and to write less.code. Anyone, including non coders, can pickup a handful of tags and function in a day and know enough to add some basic functionality to their site. Whether it be outputting a few queries to a page or writing a simple admin for editing some db records.
If someone who needs such basic functionality is bombarded with oop, frameworks,.cfc`s etc, don't you think that is more likely to put them off cf?
It multiplies their learning curve exponentia and suddenly cf doesnt seem so simple anymore. One may s well just use php in that case and they will probably find one of the many thousands of off the shelf apps does what they need anyway.
I think it is great of.course that cf can no longer be accused of "not being a real programming language", and caters for both ends of the spectrum, but i wish the community would respect this as well and allow folks,.esp newbies to be at the simple procederal tag based end without being blasted.for it, just remember what attracted most people to cf in the first place, probably even you.

Coldfusion's greatest flaw is that it is too easy to use. Because that any idiot with a keyboard can start building spagetti code that somewhere down the line is going to turn into a maintenance nightmare and in many cases cost businesses money. Programmers who learn to build things in the OO model are having their hands forced to encapsulate there code. Most people don't pick up OO on their own like many CF developers do. There is usually some formal training that hopefully teaches them a few best practices too.

The same encapsulation that they are doing in OO can be done just as well in most cases with CFCs (and storedprocs) by a good CF developer. Unfortunately many developers in all languages don't spend enough time thinking about change management Encapsulation through OO or cfcs/procs is essential for any app that plans to live in the real world. You can accomplish most of the 'benifits' of OO in your CF code without actually building objects.

Obviously you can right bad code in any language, but the lack of training needed to use CF and procedural programming in general is always going to be both a benifit and a black mark for CF.

@Matt,

I am guesing you only do cf, cozz newbie or poor developers write spagetti code in all languages, cf has no patent on this.
In fact spagetti code in cfml is still better than other languages due to the fact that cfml is in itself a framework which encapsulates much complex code in tags, which results in much less spagetti code than say php, where the developer would have to write all the code that the cfml tags do for you.
So the simple learning curve of cfml is actually not a flaw at all but its greatest feature as it is actually far harder to write really bad code.
Training is not required for any language and very few devs do training unless provided by their employer, most will just use online tutorials and resources to learn.
Again this is a major benefit for cfml as you really only need to learn a handful of tags and functions for a basic site, not the entire language.
You can then expand slowly into cfc components, frameworks and oops if you want, if you dont want then you can stick with plain ole cf tags.

@snake,

CFML is not a framework, it is a language which provides a layer of abstraction for programmers. ColdBox is a framework. Mach II is a framework. Frameworks provide a set of specific guidelines to follow when constructing software *while using a particular language*, to provide consistency and ease of maintainability.

There's nothing forcing a CF developer to be consistent unless they choose to adopt a framework, even one of a home-brewed nature. However, this is not required.

And...I'd argue...that other languages make it much more difficult to do things incorrectly, esp. those of a static type / compiled nature.

It is not hard to write bad CFML code at all. It happens every day...and is what drives us to make these posts and pound desks. It's "ok" to stop justifying why you don't have to play by the rules when you use CF to build apps.

I'm still amazed that some CF developers actually defend the right to do what they want, and that they shouldn't have to be forced to "learn best practices" or "try new approaches" with their code...like it's some sort of personal attack on their skill-set.

Some want to improve.

@Snake,

I have inherited dozens of sites/apps in CF, C#, VB, and PHP mostly small to medium scale sites, so I think I have a pretty good handle on how various languages get used. PHP sites tend to be the worst, probably because people that won't pay for hosting wont pay for a decent developer either. In my experience, the CF sites are consistently worse than the C# and VB sites.

My point is not about the languages, it is that good practices are tied to the developer and not the language. There is a lot of good practices that are built into OO that can be incorporated into CF developement. I think that it is possible in CF to incorporate many of the benifits of OO by encapsulating your code well without incurring the extra overhead and development time that a full OO app would have.

I also think that my point about ease of development being BOTH positive and negative is well founded. Obviously there is plenty of bad code in all languages, but I really do think the problem is worse in CF because of it's ease of use. I have repeatedly seen top management make the switch away from CF because the work of an amature CF developer cost them big. They usually have no idea what goes on under the hood so they blame CF. I saw it quoted somewhere (possible on this blog) that in the old days Nobody got fired for buying IBM. Today it's the same thing. Nobody gets fired for recomending the established OO languages (C#,VB,Java), but people do get fired for recomending CF. I strongly believe that CF in the right hands has a significant cost advantage over those other languages, but people in the CF comunity need to realize that CF has a bad name in many circles and it is tied directly to the quality of the coding on some of the CF apps out there.

This is getting off topic, so I'll leave it there and resist responding to any non OO comments here.

@Shawn,
I wont attempt to argue with you over what CF is, I can only suggest you go and read the cf docs at www.adobe.com and get confirmation from Adobe themselves about what CFML is classed as, it has been the same since the days of Allaire, you should also read up on what makes a framework a framework to help you understand why that is the case.

There is nothing forcing any developer in any popular web language to be consistent, again this is nothing specific to CFML, it occurs everywhere. However there is a certain amount of consistency built into CF from the outset by its whole tag based framework.
For example, database queries, sending emails, uploading files... these things will always be consistently done the same way in CFML because they will always be handled by the tags that do those things.
If you did the same in PHP or ASP then the code could be different each time.

I did not say other languages make it more difficult to do things incorrectly, I actually said the total opposite, other languages make it easier, see above example as 1 reason why.

It is quite possible to write good code without using any 3rd party frameworks or other peoples best practices, in fact developers have been doing this for many many years before such things even existed. Who do you think created all the frameworks and best practices in the first place?

Any developer should be free to choose how he works without having some other arrogant sod try to force their own preferences down their throat and telling them what they are doing is wrong unless they do it his way.
If he is writing crap spaghetti code, then that is his own lookout and he wont be getting much work, the more for you.

One obvious reason why CFML may seem to have more spaghetti code is simply because there are far less CFML developers and apps than there are PHP developers and app, CFML is a small niche by comparison.
It is like saying black presidents are worse than white presidents because more black presidents have done a bad job. Clearly it is not a fair or equal comparison.

Sadly this is one of the big reasons why the CFML community has become so quiet and why the number of new cfml developers has diminished as result. Newbies are scared off by this "you must do everything this way or burn in hell" attitude which completely goes against all the benefits and ethos of CFML.

I have seen people post 1 question on cf-talk, get unhelpful responses telling them they should be using coldbox, oop, ORM yada yada which suddenly makes CFML seem like and a horrible complex monster, and they dump CF in favour of something else (PHP).
It really doesn't give a good first impression to people interested in learning CFML.

@snake,

Thanks for the update on the documentation @ Adobe. It's clear in many developers' eyes that they have a unified, focused vision on what ColdFusion is, and where it is headed.

It's also opinion...which (as we've seen thanks to the likes of Apple) has been called into question numerous times.

Implying that CFML is a framework based on the fact that it is comprised of a consistent set of tag-based constructs is short-sighted. *Many* programming languages possess syntactical constructs that follow a set pattern.

...that doesn't mean the language is a framework.

Is it possible to write good quality, easily maintained code without a framework? Absolutely.

Is it done in practice in CFML? Rarely. I can't speak for some of the other folks in the community, but I've clocked 15 years in thus far, and can count on one hand the number of previously-constructed CF-based apps that I've had to maintain that I would consider clean, quality code.

The rest is shit.

Absolute. Total. Shit.

Honestly, I don't hold it against them, because in many cases with CF developers (and this is very true in many languages), the jr. level developers who finish their day off by clocking out and never giving a second thought to their improving their craft...are the very same folks who justify why it is "ok to just do whatever".

Thanks to the hard work of Ben here, and other folks in the community like Ray Camden and so on, *real* time and energy is put into providing new insight into the craft of CF. How can things be done better? What more efficient ways can we construct software CF? And Thank God there are folks out there willing to do it.

Because there are always...*always* going to be developers, who read these posts, on how to sharpen their skills and learn from those who have already tried->failed->learned->grown, and wish to share their experiences...

...and say things like "Any developer should be free to choose how he works without having some other arrogant sod try to force their own preferences down their throat and telling them what they are doing is wrong unless they do it his way."

@Shawn,

If you disagree with Adobe's definition of ColdFusion (and Macromedia's before them, and Allaire's before them) and where you think it is headed, then I can only suggest you contact Adobe directly and take that up with them.

Personally I like CFML and i'm more into supporting and growing the community and that is where my time and efforts are spent rather than slagging everyone off for their coding ability, which I don't feel is constructive.

@snake,

I also like CFML, but I'm "more into" supporting the education and growth of the community, in an attempt to provide them with new insight into development practices, so they continually grow and improve...and not come up with reasons why they consistently *shouldn't* grow and improve.

Option A:
"Don't do X Y Z, because nobody should have to force you to anything, there's no rules anywhere that say you should or should not."

Option B:
"Perhaps you should consider X Y Z, even though it may challenge you, and isn't something you're familiar or comfortable with, it will grow you as a developer."

Now...which one of these was the one you felt was the constructive version?

@Shawn,
a friendly suggestion is ok, but that is very rarely what happens and is certainly not how your coming across either, I cannot imagine the "do it this way or you are shit, your code is shit and should never ever touch code again" approach is really going to come across too well with anyone.

If someone just needs to query a database and display some info on a webpage then there is absolutely no requirement to learn a framework and oop for something that simple, it over complicating something simple just for the sake of it, which completely defeats the simplicity of CFML.

While it is absolutely true that an object-oriented framework is *not* necessarily the right thing to do with every single application that is built, what we tend to see more and more in practice is that applications which fall under this umbrella (ie. "Hey, can you whip me up a quick webpage that dumps our employee database to an Excel spreadsheet?") often start out as simple one-off apps...

...and then grow.

They are given more functionality, more responsibility, extend their reach further out into other systems, until it becomes a tangled mess of spaghetti code.

Why does this happen? Because jr. level developers lack the foresight to approach solving their problems from a broad sense--it is something that comes with time and experience. They hyper focus on the quick-and-dirty solution, and do not think about the far reaching ramifications of their design decisions.

As time goes on, and their beliefs about software development aren't challenged, they begin to solidify these beliefs into rigorous ideals. "I've never had a need for a framework, and nobody does, honestly!" --and then, they return to maintain and support a monolithic beast that they are perfectly comfortable maintaining...

...because they know no differently.

But a seasoned programmer who has already suffered through those experience could bring fresh perspective to the table. They could potentially look at the large problem, rather than each granular issue--and come up with a clean, consistent structure which is easy to follow, and cleanly divides this beast into formulaic, separate systems. In many cases, it's as simple as separating display logic from business logic.

Even by doing this simple task, and doing it by hand (rather than relying on an outside set of code that's been written already), one has begun the process to lean towards a *framework*. And in very many cases, these frameworks happen to employ object-oriented concepts. Which work very well...in many cases (but not all!)

The point is that: as a developer in an industry that is ever changing, each problem is unique and must be addressed as such. Will a framework be necessary in every case? Nope. Will object-oriented development always be required? Not at all.

...does that give you an excuse to NEVER learn about it? NEVER put it into practice?

No. It does not.

No programmer is excused from not learning new techniques.

If you are a welder, you have a finite amount of welds you can perform. You go to school for month, learn the welds, get your welding ticket and are done. If you weld for your entire life, you will only ever weld using those techniques you learned during certification.

Software development is different. You don't get the luxury of a finite amount of ways to build software. Your job is to continually be aware of what is new, how things have changed, improved, and what you can embrace to become more efficient and more experienced.

It *starts* with "just querying a database"...but it never ends there.

It never ends, period.

I could not agree more. I know that OOP does have it's advantages. But, for a lot of web apps, the server runs the script, then "poof", the server-side script is out of the picture. What's the point of creating objects in a server-side language if they're just going to disappear once the page loads :)

Now, JavaScript or Native App development - I don't know how you'd survive without OOP.

@Phil,

You simply need to persist your object to avoid that scenario, which is what application scope is for.
If you need to re-use the same object over and over on multiple pages then it would be daft not to persist it in memory.
For objects that are specific to a user, such as a shopping cart, you would store that in the session scope, which of course is also persistent.

Great discussion guys. I am a Coldfusion, J2EE, .NET, and Objective C (iPhone Apps) developer.

I started out on Coldfusion and loved it's simplicity and the speed to develop simple web pages for my smaller clients. I see similarities between PHP and Coldfusion, except that it is easier to use OOP in PHP. I generally don't think it is worth the overhead to OOP in Coldfusion. It would be better to switch to a pure OOP language and framework like J2EE when you truly need OOP. So when do you truly need OOP. As a Coldfusion developer it might be difficult to make this decision, because you might not have any OOP experience working on platforms like J2EE or .NET.

There comes a threshold in an app where the benefits of using a true OOP platform outways Coldfusion. It usually has to do with the size of the project.

It would be a bad choice to implement a big financial system for a company like Verizon or AT&T using Coldfusion. Look at the general company sizes where Coldfusion is used as the primary language. These companies tend to be smaller in nature with smaller projects. It makes sense to use Coldfusion where the cost of entry is less than hiring $100K plus J2EE architects and developers to build smaller apps that could be built faster with lower overhead in straight Coldfusion.

Another point is that in pure OOP languages, the developer is forced to make design decisions when building classes and interfaces. These decisions make the developer think about how the app might be used in the future. In general this results in better designed code that could lead to more maintainable code. I have found that it is also easier to delegate pieces of an OOP project to developers, due to the encapsulation nature of OOP.

Under the hood of Coldfusion, it is running on a J2EE platform using pure OOP. Why was it done this way? Why was a procedural language not used to develop this cool app?
Because:
1. It is a huge and complex software package
2. There have been thousands of developers working on it over the years where code maintainability becomes very important
3. Certain software design principles needed to be implemented and a platform like J2EE with a language like Java makes it easier (and sometimes enforces) those design principles. These design principles can lead to optimized threading, IO, maintainability, security, scaling abilities and code readability. Many add-ons also exist that make things like TDD (test driven development) a breeze in J2EE (JUNIT) and .NET.

I have found in my OOP environments that good code maintainability and readability are expected from developers. I don't see that so much in my Coldfusion environments (good for developer, bad for client or company). That does not mean maintainability and readability cannot be enforced, but due to the nature of Coldfusion it takes extra effort to do that.

With Java/J2EE maintainability is very much part of your daily activities since you start by writing a class that will be instantiated as an object. So now you are thinking, what should be a class? Will this class need to be abstract? Should I build it as an interface? Who will be using this class? White kind of design pattern should I use to make this app super fast and easier to code? You are forced to make these decisions by just starting to code. This takes time and money. It makes sense for large scope projects, but not for small ones in small companies.

If you are using Coldfusion I don't think it makes sense to try and OOP your code. Just stick to CFC's and page templates for re-use and good file naming and commenting for readability. I do recommend learning another language and platform like Java/J2EE to see how cool things can be done in larger apps.