Procedual Programming vs Object Oriented Programming - Part 1

This is a topic every developer must deal with at some point in their life.  I broke this article down into several parts.  The first part is about procedural programming, the second part is about object oriented programming, and the last part is the summary.


I did a search earlier on the pros and cons of procedural programming.  I could only get a few results.  The few results I did get were contradicting themselves.  One of the pros stated that procedural programming resulted in portable source code.  One of the cons stated a change in the application means you'll have to rewrite much of the code.  Those two contradict each other.  I'm sure there are instances when you can copy/paste and everything will work out fine.  I can assure you, that 90% of the time you'll be doing a rewrite of the great portable source code.

Another pro to procedural programming that I found stated that it's easier to maintain as you can test a procedure in isolation.  While this sounds great in theory, this is also a contradiction.  Most procedural programs require a higher usage of public variables.  So when creating your tests, you'll have to account for every variable that the procedure uses.  I hope you're religious as you'll be praying that you don't have to test this 500 line behemoth procedure.  Maybe if the procedure was divided into many smaller procedures it would be better, but I wouldn't hold your breath.

Another pro for procedural programming I found stated that your code is more flexible as you can change a specific procedure that gets implemented across the program.  I'm pretty sure they meant a procedure that is not overloaded and that they don't touch the input/output of the procedure.  Otherwise, this pro is surely a con.

Let me explain my list of pros and cons for procedural programming.

Pros

• Easier to follow along as you can step through everything.  Objects are rarely abstracted so each object you come across should make sense immediately.
• As long as the input/output in your procedures don't change you can modify it fairly easily.  Testing may make this a con as you will need to ensure that this procedure relies on the absolute minimum requirements.
• You can quickly create code and use existing procedures without requiring much thought.

Cons

• Harder to maintain (if a team is making the application) as a change (or no change) in a global variable will trickle down through all procedures that use it.
• An input/output change will more often than not require a rewrite of several procedures that lead up to and follow the procedure being changed.
• An incorrectly handled exception can be devastating as any follow up procedures may be using incorrect or no data that it requires.  (This is the same for OOP, but in some instances OOP won't cause as much devastation - Covered more in part 3.)
• A lack of some structure can create frustration because of a lack of understanding what the procedure is supposed to do.  (AddOrder(order) and SubmitOrder(order) has similar meanings.  One may mean to add an order to a cart while the other is to submit the order for execution.)

Procedural programming is great for really small teams (2 or less) that are creating really small applications.  The more team members and the larger the product will make the cons I mentioned earlier stick out farther and farther.  You can easily add functionality with procedural programming, but modifying functionality can either be easy or near impossible.  There's not much of an in between.