What is “Procedural Programming”?

imageIn short, procedure programming is non Object Oriented Programming.  In procedural programming, a programmer designs a flow of the program, either on paper, or with a flow charting program, or just has a clear, mental image of how it’s going to work.  The program starts in an entry subroutine, then it calls other subroutines, and they call subroutines, and so on.  There are logical decisions made in the code to decide which routine to call when.  Programs written before GUIs (Graphical User Interfaces… Like the Macintosh and Windows) were available, were written with this style of flow being the primary designing concept.  Essentially, the program was made of many procedures that called each other.  There was a definite algorithm and a strict flow of control.

 

Event Driven Programming:

image Later, after GUIs arrived, the game changed.  Programs didn’t start up like they used to and take control and flow and do their thing until they ended anymore.  Instead, the GUI would send “events” to the program.  In other words, the GUI was in control, not the program.  When the user clicked on a visual component, the GUI would send a message to the program that was clicked on, providing the component that was clicked on and the coordinates inside the component where the click happened.  Also, any typing on the keyboard triggers events to be sent as messages to the program.  With this paradigm shift, programs were no longer procedural, but were then “event driven”.  The program essentially would just sit idle, until a message was sent to it, informing it that something just happened.  The program would examine the event and take appropriate action, then sit and wait again.

OOP (Object Oriented Programming):

image OOP was the next step in programming.  GUIs were object oriented in concept, even if not implemented with a true object oriented language.  Object oriented language is not necessarily different from procedure programming.  It’s a superset of it.  In other words, you can still write your code with an object oriented language, but still in a procedural manner.  As a matter of fact, you still have small procedures scattered throughout.  The primary shift is that you think in terms of “objects” while you’re designing and programming, rather than in terms of “flow control”.  It’s a different way of thinking.  It’s much more modularized.  See this article for a more detailed explanation.

Leave a Reply