Object Oriented programming has come up again as a topic du jour and is quite possibly one of the more divisive topics in the ColdFusion world, apart from Framework religion of course.
Some may view OO as a smarter way to code. Some may view OO as a pain inflicted upon them by a Development Manager. Some may view OO as simply another elitist autocategorization. “Hey man, I am more 1337 than you. Even nOOb has OO in it, har har har. I have felt all of the above at one time or another.
Personally, I was a happy procedural programmer for 4 years. I could crank out apps fast and respond to changing market needs. I could implement unique and clever ways of solving problems. I could get it DONE BABY!
Then suddenly, I took a job with a very prestigious organization and was tasked with building ColdFusion applications using MachII and OO techniques. Man, was I confused! I felt like Michael Vick at the global PETA conference. I buckled down and with the help of mentors, a lot of mistakes, and prodigious self-study and experimentation, I grew into OO programming.
Despite what you hear, OO is not only about the use or disuse of the 5+1 pattern. OO, and its proponents can be very academic, but let me assure you, there is a valuble practical side to it all. Allow me a story:
A long time ago, all machines were made completely by hand. Precision was a treasured skill among craftsmen and machinery parts were fitted together in a manner that was no more complicated than necessary.
As machines were responsible for increasing productivity and reducing manual labor, the machines were prized. If a machine broke due to a faulty fozzbob, a master craftsman analyzed the system, took an ingot of iron and crafted a replacement fozzbob. Certainly this took time, and no work could be done whilst the machine was out of order, but these things happen. Should the machine need upfittment to fulfill new requirements of the customer, a lengthy and expensive series of work took place. Sounds Painful?, It was but there were no alternatives.
Fast forward a few years to the perfection of the ‘replaceable part’. The idea being that a part made for one specific type of machine would fit in another machine of the same type equally well. Machines went on increasing productivity and reducing manual labor and when the fozzbob broke, one simply swapped the fozzbob and the factory was back to Regularly Scheduled Manufacturing. Should the machine require an upgrade, the upgrade could be added to the machine with little downtime and little custom work. Sounds more efficient, doesn’t it?
Fast forward a few years to the automotive industry. Some clever chap named Bob Lutz came up with the idea to produce platform vehicles. As all vehicles require engines, frames, suspensions, steering assemblies and other ‘infrastructure’ components, why not build a platform that could be utilized on several makes of automobiles? This reduced the overall vehicle cost due to economy of scale.
A modern day example of this is the Hyundai Santa Fe SUV. From the exterior, the Hyundai Santa Fe is a normal and fine example of an SUV. Underneath, the Santa Fe shares an inordinate amount of parts with the Hyundai Sonata. Certainly this required additional effort to create platform parts for both vehicles. The parts are even more complex at the individual scale. Overall the interchangeability, extensibility and economy gained by increasing the complexity certainly justified the cost.
If we had a Jules Verne time machine and transported a Master Carriage Craftsman from 1800 to the modern day, I imagine the Craftsman would not be comfortable with the additional complexity, the additional engineering and the inefficiencies at the small scale. The Craftsman would wholeheartedly reject the entire concept. After all, this Craftsman has build hundreds of machines before.
Getting back to programming, I’ll admit the business of object oriented programming can viewed as overly complex at times. The indirection can seem inefficient at times. The logic can seem convoluted at times. The plethora of terms can seem overly annoying at times. The elitism can seem completed unfounded useless at times.
Be assured that all machinery/software will break down. Machinery/software needs to be enhanced to meet changing demand. Machinery/software requires maintenance to function.
As an object oriented programmer, my mission is not only to analyze and design a functional and useful application, but to craft the inner machinery to be relevant, reusable and replaceable. I no longer simply handcraft each module in isolation, I design interchangeable parts.