In some respects, with the release of ColdFusion MX 6/6.1 and the beginnings of some object oriented (OO) capabilities in ColdFusion, the developer community has been split. On one side, there are those developers who came from Java, SmallTalk, .NET or some other object oriented capable language and were able to pick up the concepts of object oriented application development in ColdFusion fairly easily. On the other side, are the developers who came into ColdFusion new, or at least without any object oriented development experience.
To many of these developers whose tried and true procedural methods have worked just fine so far, object oriented development is completely foreign and un-trusted. I was talking with one such developer the other day, that had been presented with an opportunity that required object oriented development skills. So, what benefits do you give a procedural programmer for shifting to object oriented development when their procedural ways have been serving them just fine for many years?
Real World Modeling
In most applications, we are asked to model some sort of real work scenario. Maybe it is a content management system where users are being asked to publish content and that content goes through a workflow process before being made available. You can fairly easily imagine a newspaper editing room where the writer hands off his article to a publisher who must approve it before going to print. This is a real world model.
Take an e-commerce application as another example. You can picture a customer selecting a product from the shelf, approaching the cashier, providing payment information, and leaving with their purchase. This is a real world model.
Object oriented development is all about real world modeling. With object oriented development, you have a series of independent objects – a customer, a shopping cart, a payment processor, etc. These objects are self contained and know how to perform a limited number of functions. Putting them together into a system though, and all of the sudden you have the building blocks of a full blown e-commerce application. Object oriented development allows you to build an application at the functional level, and not at the implementation level like you do with procedural development.
Code Reuse
In other trades, there are proven solutions that people rely upon every day without re-inventing the wheel. For example, the builder doesn’t go out to the forest and start chopping trees for a new house. He uses a common 2"x4" wood to frame the house with a hammer and nails that somebody else already developed. So, why do we as software developers spend so much time re-inventing the wheel with each new application? How many applications have you built that require a user authentication / authorization system? Sure, there may be some added complexities in some cases, but the general principles remain the same.
With object oriented development, you can very easily reuse previously build objects and subsystems in a new application. These objects have been built, tested, and proven in other applications, so you can easily drop them into your application and expect them to work. Through other object oriented development practices, it is easy to extend and enhance the capabilities of an existing object without changing the original code. This improves avoids adding new bugs to the system and speeds your development time.
Reliability
Reliability is a key factor in delivering software applications. After all, what use is an application that keeps crashing or loosing data? As mentioned above, object oriented development is all about small modular components. By developing using these small components, the developer can write and test a small piece of functionality independent of the rest of the application. Then, when working on other aspects of the application, he can assume that that component or object works as advertised. Working in this kind of environment allows you to isolate and test functionality with confidence rather than just using some high level test cases and hoping none of the fringe cases that were missed cause any errors down the road.
Maintenance
Customers and developers can be so focused on the cost and time to develop and application. The customer always wants it done faster and cheaper. However, it has been shown that 60% to 80% of the time and effort spent on an application is done after initial release – in the maintenance phase. Well designed object oriented code is maintainable. If a bug exists, you only need to fix it in one place. With object oriented development, a change to the implementation is invisible to the rest of the application, so no additional fixes or testing is needed and the rest of the application automatically benefits from the change.
Future Expansion
Most of us have never experienced a project whose scope grows or have a customer who comes back wanting new enhancements. But, for those of us who do, object oriented development can assist here as well. Object oriented development has features and principles that allow for easy expansion of applications through things like encapsulation, inheritance, delegation, and design patterns. In addition, pre-existing modules should not have to be retested as objects only relate to each other through their interface without any knowledge of the implementation of the object.
Wrap Up
This was a lot to cover in a "short" article, but hopefully it has piqued some interest in object oriented development. In future articles, I plan to look at some of the common pitfalls that come with object oriented development (it’s really not the end all solution to the world’s problems) as well as start looking at some of the major principles of object oriented development with relation to ColdFusion.
DougHughes.net 
Comments on: "What does Object Oriented Programming do for Me?" (14)
Doug, thanks for posting this! Your high-level examples are perfect and I think you segregated the two types of CF developers very accurately. So what to do to get everyone on board with OO.
For starters the book Advanced ActionScript 3 with Design Patterns is an excellent book for anybody (regardless if they are programming in AS3, Java, CF or whatever). It provides solid proven concepts and should be in every developer’s library!
LikeLike
I agree that you’re right about the two types of CF developers. And I’m clearly in the camp of those coming from procedural programming– I understand the syntax of OO code, and I’ve started to write some over the past couple of years, but I have a huge codebase of procedural CF code and I haven’t made the leap to writing fully OO code. But I’m working on that transation.
I think your article– and articles like it– miss something important about procedural code. All of the benefits that are touted for good object oriented code also apply to good procedural code: real-world modeling, code reuse, modular design for reliability, and coding for maintenance are aspects of a good procedural architecture too! In fact in some cases, it seems to me that OO design adds complexity and hurts maintainability, because the large number of possible interactions between objects are not always well-defined or test within the system.
Although you don’t do this in your article, I’ll mention that it particularly annoys me when I hear OO programmers using the terms “procedural code” and “spaghetti code” as though they were synonyms. Spaghetti code is badly written, badly designed procedural code. What do you call badly written, badly designed OO code? Because there’s plenty of it out there.
LikeLike
David –
You have valid points. Just because somebody writes object oriented code does not mean that it is good code. It is just as easy to write bad code using object oriented development principles (maybe even easier) as it is to write bad code using procedural development principles.
The difference between procedural development and object oriented development with relation to these “benefits” is that if written correctly, object oriented code automatically exhibits these benefits. Procedural development has to be formed and planned to exhibit these benefits. While this is quite possible, it is not the natural flow.
Does this mean object oriented development methodologies are better? No. Just like it is impossible to make a blanket statement that ColdFusion is better than PHP or .NET, there are good points to both procedural and object oriented development styles. The point of this article was to introduce some of the benefits to object oriented development for developers who have not had a background in object oriented development and are getting bombarded with all of the technical aspects without any of the background.
Thanks for your feedback.
LikeLike
I can respond by saying that if you write procedural code “correctly” then it “automatically” exhibits these features also! And, for the team I work with, we have a long list of rules, procedures, and customs to make sure that code is written “correctly.” (which is not to say that we never make mistakes!)
From my outsider perspective, it looks like the real benefit of OO– much like the benefit of working with an application development framework– is that there are some really well-defined practices that experienced OO practitioners will agree on that define what it means to write OO code correctly.
While the standards my team uses on our procedural code really apply only inside our office, and are the results of many years of making mistakes and defining the structure of our applications, the general principles of OO design will apply to nearly any project written by nearly any team in nearly any OO language (with slight modifications).
Right?
LikeLike
Kyle – I wanted to make the point that Jeff has been blogging on my site while we get an official Alagad blog up and running (eventually). Please give credit to Jeff Chastain for this entry.
LikeLike
hi I liked the article, can I reproduce it on cfpaperclip.com as one of the articles on CF & OOP?
All credit and links back to this article and site will be added of course.
LikeLike
Hector – Sure, feel free.
Thanks.
LikeLike
@Jeff, good article. Great starter on the benefits of OO but of course it only scratches the surface 🙂
@David C-L, no, the best procedural code does *not* “automatically” exhibit these principles or benefits. Certainly “good” procedural code is much better than “bad” procedural code (and better than “bad” OO code too). However, OO brings a couple of fundamental shifts that allow an inherently better approach to modeling and code reuse (and hence maintainability and reliability). The key is associating data with behavior and providing encapsulation. That simply isn’t possible in procedural code – data and behavior are always separate. The ability to encapsulate data (and also to encapsulate behavior by restricting who can call certain methods), is what gives OO its edge over the very best procedural practices.
But OO takes time. I started doing OO in January 1992 after being a procedural programmer for well over a decade (heck, I was an assembler programmer for a few years!). My first OO attempts were painfully awful. I’m still learning new tricks today (if a day goes by when you don’t learn something new, you’re not trying hard enough!). Sometimes OO just seems like a lot of extra code and a lot of work. And a bad OO design will punish you more than any bad procedural design you’ve ever conceived. Over time, the benefits become more and more self-evident and they’re often hard to quantify (simply because we, as an industry, just don’t measure our performance in enough detail to verify whether a change of process improves things or not!).
LikeLike
Thanks for the feedback, Sean. I’m sure this will all become clearer to me as I write more OO code.
LikeLike
OO development is definitely an ongoing learning experience. Luckily, I had the benefit of starting my programming career in OO development, before moving to the web and experiencing procedural styles later. But like Sean said, it is still a learning experience every day. That is one benefit to putting together articles like this – you get to study concepts and learn more yourself while hopefully helping others at the same time.
Thanks for the positive feedback. Now if Doug will let me have a few minutes to post a bit more often!
LikeLike
do you have a daughter jeff?
LikeLike
I am unable to find the proper definition of oop.so please send me the proper answer.
LikeLike
I don’t agree with all your points! I still can reuse my code EVEN without OOP by simply cutting and pasting my code/function (ex. user authentication / authorization system) and that’s work fine same as OOP! There’s no need to superimpose some elaborate structure of interacting, instantiated objects, with all the messaging and fragility that it introduces into a program.
secondly, OOP is not more Reliable than procedural Programming, if procedural code can crash, then OO can crash too in the same way, what can make the code crash is the programmer not the WAY he coded the program (OO or Procedural).
LikeLike
The description above is what’s widely known as hand waving. It doesn’t mention a single feature specific to object oriented design that improves the state of the software. Rather it just mentions a bunch of wonderful qualities, and attributes those qualities to object oriented design. What does dynamic dispath buy you? Subtype polymorphism? Isolation of an object as its own Finite State Machine? The article as written is hype and hot air. It could use some specifics to make it real.
LikeLike