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.
The Difference
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 objects 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 persons weight? What would happen if that other object set the persons 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 objects weight, that setter function could have some logic built in to know that a persons weight cannot be below 0, so it would throw an error if a negative value was attempted.
Thats 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.
DougHughes.net 
Comments on: "What's the Difference?" (11)
Jeff,
I like your concise description of the differences between these two approaches.
In fact, I wanted to give the post 4 stars. But, that functionality appears to be broken. (Doug, didn’t you run the unit test for that?)
Anyway, this post gets a place in my bookmarks.
Thanks Jeff.
LikeLike
A few additional comments:
1) “Multiple functions have access to global data”
Developing procedural code should still follow encapsulation rules and procedures (or subroutines, or functions) should not be accessing global data.
2) “an object is made up of attributes and behaviors”
So is an Abstract Data Type (ADT), the procedural parallel to an OO object. Everything you say about objects applies to ADTs.
3) It sounds to me that you are describing the differences between OO and procedural based on a misunderstood view of procedural development.
The true differences is in the design approach or the object model. OO tries to mimic the real world, and is (theoretically) easier for the non-programmer to understand. Procedural tries to mimic the way the computer would approach the problem (one step at a time).
The real differences between the OO and Procedural paradigms is inheritance and polymorphism.
Inheritance is great when trying to mimic the real world (as in OO). It doesn’t make a lot of sense when you’re trying to break things up in a step-wise manner so it’s easy for the computer to process the problem (as in procedural).
Polymorphism means that different objects can respond to the same methods. When you write code (a method), and don’t know what type of object you’ll receive as an argument, you specify that object input as an interface, which defines the needed method. All objects passed in must implement that interface.
It is easy in a procedural language to make different ADTs respond to the same method. But it is very hard to write code that will accept multiple ADT types as arguments.
In a dynamic typed language, such as CF, you won’t be performing compiler time type checking, and polymorphism is very easy to implement w/ procedural designed code.
4) The closest CF comes to having “true” subroutines is with custom tags. I’d love to see them added, but am not holding my breath. It is really just syntactical sugar since UDFs and custom tags provide functionality that is ‘close enough’.
LikeLike
Jeffry – While you make very valid and correct points, that is not what I am trying to get at here. It is quite possible to write very good, encapsulated procedural code that follows many of the best practices of object oriented development. It is also quite possible to write very bad object oriented code that follows none of the best practices of object oriented development.
What I was going for here was a basic comparison between the two methods of coding and what each brings to the table from the most basic level. How “good” the code is from either a procedural or object oriented standpoint still lies with the skillset of the developer.
LikeLike
Jeff,
After re-reading your post, I do not to see where you actually discuss the differences between OO and procedural development.
I would expect a discussion of differences might include items like inheritance, polymorphism, and the intent of the ‘model’ design. Instead you spoke of global data vs local data, which is not a procedural vs OO issue.
It was the data comment that prompted my original response and I just went off on a rant from there.
LikeLike
Jeffry – The differences between object oriented and procedural development are not inheritance, polymorphism, and encapsulation. In fact, I specifically avoided using these terms as I was attempting to approach this from a more object oriented novice level.
The real difference between object oriented development and procedural development – especially from a traditionally procedural developer’s standpoint – is the way data and functionality are treated. As I mentioned, with typical procedural development, data and functionality and free flowing with the goal being to get from point A to point B. With object oriented development, much more focus is put into the concept of objects that each have their own collection of data and functionality and related/interact with each other to then provide a much larger piece of functionality.
Inheritance, polymorphism, and encapsulation are concepts that good object oriented development make use of, but they are not the defining factors behind object oriented development. Way too often, object oriented developers jump in with all of these big buzz words without stopping to think about who the audience is and that that audience may have no idea what a constructor is, much less polymorphism.
My approach for this article, and probably a series of others, is to take this from a novice object oriented developer stand point and build from there. Will I get to things like inheritance and encapsulation? Sure, they are core practices in object oriented development. However, if you are to look at the basic concept of what separates procedural development from object oriented development – that would be objects and they way data and functionality are treated. This was the core idea behind this posting.
LikeLike
Jeff,
[quote]
“As I mentioned, with typical procedural development, data and functionality and free flowing with the goal being to get from point A to point B.”
[ end quote ]
I don’t know what “free-flowing” means when used in this context, so I’d love to see a clarification of this sentence.
But, that aside…
I never meant to say encapsulation was a difference between OO and procedural development. I’m sorry if I did, since that is obviously wrong. Encapsulation is a generic concept that applies to any programming approach.
I agree that the differences between OO and Procedural is the way that data and functionality are treated. I intended to say that in my previous comment when I mentioned that “the intent of the model design”. Perhaps, describing this as “the approach to the model design” is better wording?
This is how I would describe the difference:
1) OO tries to organize code in a way that mimics the real world.
2) Procedural tries to organize code in a way that makes it easy for the computer to process it.
I don’t believe the difference was addressed appropriately in the original post. I think the statement that the difference is in how “data and functionality are treated” is an elegant description.
I believe the article’s discussion of how procedural code treats data and functionality was inaccurate. The article starts with the incorrect statement that procedural development accesses global data. Then it talks about how objects are different. When in fact, they aren’t any different than Abstract Data Types (based on criteria discussed in the article).
LikeLike
Please can someone treat this questions below? Thanmks:
“The reason why OO has become such an important business information systems development approach AND also the Global issues in relation to systems development and global competition AND also the problems of increasing systems complexity, interoperability, etc.”
LikeLike
Donald,
OO development principles aren’t new; in fact they were developed the same time that Procedural development was.
OO became a huge buzzword in the late 90s, and is still riding that wave. Why? I’m not quite sure.
Part of the reason is that computers got more powerful and the extra overhead associated with an OO system was no longer an issue.
It promises to be a better solution in the long term, with easier maintenance / modification than traditional development.
It is supposed to be easier to understand by non-programmer folk.
I’m not convinced any of this is true, as they often sell OO programming as a magic bullet to solve all your programming problems.
I think the overall percentage of “failed” software projects is going down (slowly), but I do not think this is due to the use OO. I think this is due to IT learning how to better communicate with their users. If you google “Percentage of failed software projects” you’ll find a few articles with details, although I couldn’t find anything too recent.
I have no idea if this answers the question.
LikeLike
Please can someone treat this questions below? Thanks
Many System Developers of business information system, who have used structured methods for many years, are adopting a radically different development philosophy based on the Object Oriented paradigm.
Question a) Discuss the reasons for the by pinpointing the environmental and technical issues
Question b) Explain the advantages that canbe gained and the problem associated with switching.
LikeLike
Are we like doing Victor’s homework or something?
Maybe I’m the only one that finds his phrasing odd …
LikeLike
Hey,
A related question, what exactly is the difference between ADTs and Objects? Aside from the pretty obvious inheritance and polymorphism.
I am asking for a top down view. What are the differnces in terms of coupling , extensibilty, simplicity , modifiability , visibility etc. etc.?
LikeLike