Apr 11 Persuing Object Oriented ColdFusion - April 5th Meeting

Posted by: SeattleZ

Hey Everyone,

April 5th was my first attended meeting and it was nice to actually learn there are more than 3 CF developers in the Puget Sound area :) Of course, the topic on Object Oriented development is something pretty close to me. I originally started in CF in 1997/1998 at Adhost as a web developer. Much like CF's lifecycle, I peaked in CFML about 2002 working for a large corporation before they made the switch to Java for enterprise web apps.

Having spent a few years doing Java and JSP since then, especially in its infancy, I've had my own crash-course and epiphany about OOP as a strictly procedural programmer. For my personal projects, its still straight CFML with custom tags as needed.

The overview Josh gave was good, though honestly I was looking for more "Reasons to use OOP". We as developers ALL know how to make things work, and arguable CF is a language where you can really shoehorn some things together to get the project done.

Here are some good reasons for OOP, but not the end all list. A well designed OO system takes longer to build than a simple scripted page. As the project grows though, you will quickly see the benefits of designing something that is object oriented at its core.

<u> - Team Development / Change Management </u>
In an OO system, developers can work on specific separate portions of the project, writing methods, designing interfaces, or working on elements without stepping on each other. These classes will work together in the end because a contract was established at project inception that says what each piece will do. This also allows subject matter experts, or people that are better at specific types of coding (DB, backend, display, architecture) to focus on their specialty. A great comparison I've heard recently is the situation where you "sew up one wound and it oozes from another." Just as Josh showed in the demo, as we change things and add features we rarely know what other component will be broken or operate differently.

<u> - Progress is always visible </u>
We've all been there, a PM wants to know how much is done. You've got HTML, CFML, CSS and other portions of your project, and many of us do the work end-to-end ourselves. In an OO system, you can literally count up the classes/methods you have completed and you'll have a rough estimate of where you are.

<u> - Front-end / Backend Independence </u>
Just as CSS has provided us a way to remove the presentation "style" code from our HTML layout, OO programming done with certain design patterns allows the front-end and back-end pieces to be disconnected. This means your backend business logic code can be finished even before the front-end pages are ready. Your front end developer can be given stubs or xml schemas and can design a page even before your app is complete.

<u> - Code Reusability </u>
Josh talked about the ability to include a "functions.cfm" type file in your project in procedural mode. Unfortunately doing this means as the application grows, ALL of your objects are loaded into memory at each execution of the base code. The code is larger, generally harder to debug, and less organized. In larger enterprise projects, we often hear of "copy-and-paste" reusability. This is probably the worst type of reuse we do in CFML, because after we fix a bug in one area, we don't know where else the same offending application code is used. In an OO system you write a method once, and your fix is applied everywhere automatically.

<u> - Testing early in the cycle </u>
As we have all seen, testing generally at the end of a project. This occurs due to the waterfall software development lifecycle. This lifecycle basically says each bucket will fill up, and once complete, the next step in the project will commence. This is horrible for rapid application development, especially because major structural errors/assumptions are not discovered until the code is finished. With OO and a good testing department, they can literally single-test/unit-test the components you build, front-end or not, early in development.

<u> - Faster Code Development / Less Defects </u>
We all know that our most troublesome requirements generally come in at the end of the project. Some of us may have developed shopping systems, only at the end of the project to hear we need to support some payment gateway we've never heard of before, or allow discount codes which were never mentioned. How one recovers from this can really show the elegance of a system/design. OO/OOAD comes at design with the idea that things will change. Changes will effect any system, but with OO you know exactly where your design is changing, and exactly what needs to change ahead of time. Additionally, with many of the OO design tools, you can generate your basic methods and code with a few clicks. Once a system is designed, you export a set of code that creates yours arrays, structures, and complex objects. You fill in the important pieces where the business logic happens, and the rest is built for you.

<u> - Code Agnostic </u>
While not really important for everyone, the design you create before you code makes it much easier to convert to another OO language and reproduce the same application. Not entirely OO related, but a fringe benefit if you plan to migrate to Java/.NET in the future within your org.

<b>CF unfortunately is not an OOP language.</b>

Big surprise. We're using a translated scripting language on top of a lower level programming language that is OO. It sounds like BlueDragon is going down the road of exposing CFM with additional capability like inheritance/abstraction.

Ok, where do you go from here if you want to learn Object Oriented CFML. I've found a couple sites that do a good job explain OO.

<a href="http://www.cfoop.org" target="_blank">http://www.cfoop.org</a>
<a href="http://www.agilemodeling.com/artifacts/classDiagram.htm" target="_blank">http://www.agilemodeling.com/artifacts/classDiagram.htm</a>
<a href="http://en.wikipedia.org/wiki/Object-oriented_programming" target="_blank">http://en.wikipedia.org/wiki/Object-oriented_programming</a>

My current employer is currently at that phase where we have an enterprise application, now
being drastically improved, but we spend a large portion of our development cycle fixing code created years ago with little documentation. Code breaks after we add new features because we're editing business logic when we change our presentation layer.

Switching to web services and OOP allows us to decouple the business logic we provide (insurance coding/compliance) from the presentation (html page, web service, pda forms, etc).

If you are interested in furthering your OOP exposure, I'm not a Sun certified expert, but I'd be happy to answer your questions and share more of our experiences.

Regards,

Jon Freeman
jfreeman@accurohealth.com
CodeCorrect, An Accuro Company
Bellevue, WA

P.S. If you want to go one step further, we are looking for quality developers interested in furthering their knowledge of CFML and OOP. You don't have to be a coding ninja, just a positive person with a desire to learn and work in a strong team. Feel free to PM me for more info on that ;)