So, what is the real difference between Object Oriented and Procedural Development?
In my last article, I listed a few of the benefits of object oriented development. It was justifiably pointed out that many of those same benefits could be applied to procedural development as well. So, I would like to take a moment and outline the real difference between Object Oriented development and Procedural development.
As a brief disclaimer, my intent and purpose here is not to say that object oriented development is the best and only way to write applications. Many developers have spent their entire development career writing procedural applications without any issue and there is no problem with that. My intent here is to shed some light on some of the basic concepts of object oriented development now that ColdFusion is trying to enter the land of object oriented development languages.
To start, what is procedural development? Procedural development is very functionally based. In other words, with procedural development, the developer develops solutions to problems. Good, clean, organized procedural development, code is broken up into smaller functions and modules that perform a specific function. These functions then act upon data that is organized into separate data structures.
So, where is the problem here? With procedural development, the data is very unpredictable. Multiple functions have access to global data, so they can only assume what the current state of the data is, as the functions have no control over that data. Because of this unpredictability, testing and debugging can be very challenging at best.
On the flip side, instead of focusing on functionality, object oriented development is much more on what the functionality is being done to. Object oriented development starts off with “things”, or objects. But instead of just being collections of functions, these objects have both data and behaviors.
In this way, objects can secure access to data, thereby protecting it and being aware of its state. Correctly designed objects only allow access to data through specific behaviors or functions. This way, changes to the object’s data may be monitored and sanitized.
What is an Object?
So, what is an object really? As mentioned before, an object is made up of attributes and behaviors. A person is an example of an object. A person has attributes … hair color, height, and weight. A person also has behaviors … walk, eat, and sleep. The biggest key here is that an object is made up of both data and functionality.
Objects have Data
With a properly design object oriented system, there is no such thing as global data. Each and every object maintains its own data set … the data that it needs to perform its job and only that data. A person object would know about its hair color, but a car object has no need for this type of data.
By keeping and maintaining its own data set, the object always knows the state of this data. In a properly designed system, the object should be the only thing that can act upon this data. Looking at the case of a person object again, would it make any sense for some other object to have control over that person’s weight? What would happen if that other object set the person’s weight to a negative value … then, we would have invalid data and be no better than procedural development. Here is where object behaviors come into play.
Objects have Behaviors
Behaviors are the functions from procedural development. With object oriented development though, these functions are grouped according to their relationship to the object. A person object would have behaviors such as walking, eating, and sleeping. A car object on the other hand would have no need to know how to eat. Functionality is unique to that object.
In addition to general functionality, behaviors serve to protect the data managed by the object. As mentioned above, one object should not be able to change the data in another object. This is accomplished by the use of specialized behaviors called getters and setters. As their names suggest, getters get data from the object while setters set data in the object. In the example above, if a setter function were used to set the person object’s weight, that setter function could have some logic built in to know that a person’s weight cannot be below 0, so it would throw an error if a negative value was attempted.
That’s a wrap for today
Hopefully at this point, you have the basic understanding of what an object is and how it differentiates procedural development from object oriented development. What you must realize at this point as a developer is that object oriented development is not just a new syntax or set rules. Object oriented development requires the developer to adjust their thinking into terms of objects and systems rather than simple solutions. This is not a trivial change, but is possible and will benefit both you and your clients when you can design code that is easy to test, debug, and reuse.