I’ve seen more than once, a person asking on a mailing list about a more ‘OO’ way to solve a problem. Often, this comes with the expectation of less lines of code to write. Certainly, as programmers paid to provide solutions, not lines of code, we want to deliver a tight and concise code base, however, OO is not about reducing the lines of code it takes to solve a problem.
Encapsulating a problem requires MORE code initially. Accounting for variability, for future extensibility and for the sake of clean architecture, it might take double or triple the lines of code than a procedural solution.
The benefits of OO come down to extensibility and to maintainability. Having a specific solution stuck neatly and tidily into a corner of your application will make alterations and enhancements easier. Often, the “OOOPs, I missed that one” problem is solved because there is less, or no code duplication.
Certainly, the more a particular encapsulated solution is used in an application, it will result in a reduction in overall lines of code. You won’t see this benefit when you write the solution the first time. You might even ask yourself, “Why did I write all that code, just to do ‘x’
“
I’ve recently picked up some consulting work on a procedural application running CF 4.51. I spent a few years working on that particular version of ColdFusion and wrote some good software. CF 4.51 has no components, no UDFs, no StructAppend and no CFDump. If I occasionally get frustrated with OO, spending an hour or two with the 4.51 based code and it’s highly procedural architecture, prove that OO is worth the time. The time it takes to invest in yourself,to learn OO and in extra time to initially code the application.
So as you explore and learn Object Oriented programming in ColdFusion, be careful of how you set your expectations. OO can be quite frustrating and annoying at times. The benefits might not be what you initially expect. The rewards come later.