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.
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 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.
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.
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.
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.