Skip to main content

11 May 2022

Object Oriented vs Procedural Programming paradigms

Javier De Las Heras profile image
Written by

Javier De Las Heras

Object Oriented Programming is a programming paradigm that applies the concept of objects in the real world. It allows to create a coded solution to a problem in manageable and reusable templates or blueprints called classes from which objects can be instantiated when needed. These Classes (blueprints) are created for broad categories, such as Vehicle or Animal with shared attributes (colour, brand, age, etc) that can have different values for each object or instance. Classes also have functions or procedures, called methods, that provide behaviours to the objects. An example of OOP would be to create a Enemy class for a game, which holds attributes (Eg; lives, strength, tool, etc) and methods (Eg; loselife(), gainstrength(), picktool()) related to Enemies. If you then want your program to create an enemy in memory, you instantiate a new object of the Enemy class.

There are any OOP programming languages such as C++, Java, Ruby, Scala or python. The 4 cornerstones of OOP are: 

  • Inheritance: a class (super or parent class) can inherit attributes and methods from other classes (sub or child classes).
  • Encapsulation: attributes can be protected or made private in order to avoid them being changed as a result of an error.
  • Polymorphism: methods from sub classes can result in different behaviours compared to the same methods in the super class.

There are advantages to this way of thinking:

  1. Modularity: Easier to test and identify and fix bugs. Objects are self-contained with their data and behaviours. Furthermore, this modularity allows a team to work on multiple objects simultaneously.
  2. Reusability of code: Suppose that you need two types of enemies, each one with slightly different behaviours and/or attributes; Inheritance can be used to create sub classes such as Dragon, Giant, etc and this would allow, with little extra code, to have many different enemies with various functionalities and characteristics.
  3. Flexibility: Polymorphism allows the same method to acquire different behaviours from the parent class. For example, a move() method can make the Giant to walk whereas it can make the Dragon to fly.
  4. Encapsulation of data: It maintains the data for objects secure as attributes can be private.
  5. Maintenance: It makes it easier to maintain, test and debug.


However, OOP has drawbacks:

  1. program size: OOP will mean more lines of code than procedural projects.
  2. Performance: OOP programs are normally slower than procedural programs.
  3. Appropriateness: OOP will not work very well to rationale programming style or strategy based programming style. Using it in these type of projects will make the code inefficient.
  4. It takes time to get used to this paradigm: It takes time for a programmer to become accustomed to it as it is a different way of thinking about a coded solution.

Let’s move now towards Procedural Programming. This is an approach based on the concept of the sub-program call. The objective of coding using this paradigm is to break down a program into a collection of variables, data structures whereas the main aim of object oriented programming is to break down a programming task into objects. 

Some advantages are that Procedural Programming is excellent for general-purpose programming, simplicity of code, source code that is very portable,  reusable in parts of the same program and less taxing on memory use. However, its major disadvantages includes program code that is harder to write, the code is often not reusable in another application, it is difficult to relate with real-world objects and the data is more exposed to the whole program, making it less secure.

In conclusion, the programming paradigm chosen will always depend on the type of language you use and the nature of the program at hand. It is vital for a-Level students to understand and know how to code using these two different approaches in order to make the correct choices when creating a programming solution to a problem.

Discussion

Richard Pawson
13/05/2022 18:39

I’m not sure whether I am falling for some kind of bait here - many of these apparently ‘system’ generated ‘discuss’ posts on CAS appear like that to me - but the statement:

‘Once a problem is decomposed into modules, these can be constructed efficiently by using objects from classes or sub-programs.’

is very misleading. Yes, you can decompose into ‘modules’ (whatever that term might mean) and then construct those modules from classes or sub-programs. But this is not following either the OOP or PP paradigm respectively - merely using different specific implementation techniques. If you are adopting one or the other paradigm (or, to bring it up to date, the Functional Programming paradigm) then how you decompose the whole problem into smaller parts - in other words what smaller parts or ‘modules’ you identify - will be different in each case. It would be normal to then continue with that same paradigm right down into the implementation detail, using a programming language and/or software frameworks optimised or at least well-suited to that paradigm. But just as it is possible to use OOP/PP/FP implementation techniques without having thought about the problem in that paradigm, it is also possible to do the reverse. The biggest benefits arise when you work consistently in a paradigm from highest-level analysis & design to lowest level implementation. Many people react against this sort of dictatorial approach, and favour ‘mixed paradigm’ approaches (often encapsulated in the phrase ‘horses for courses’ in my experience), but then they wonder why they aren’t seeing the benefits claimed for any of the paradigms!

Over the last few decades there have been various attempts to promote the idea of (programming) language- and even paradigm-independent analysis/design - usually sponsored by the vendors of CASE tools trying to to breathe new life into their dead products - but they don’t succeed, because the fundamental premise is naïve. This is one reason why experienced programmers don’t like the idea of teaching pupils ‘pseudo code’. It is better to teach pupils to ‘think’ and ‘code’ in one real language - and, if time permits, to then get them to try out a different one - than to try to invent some sort of ‘neutral’ compromise.

Pete Dring
14/05/2022 17:16

Hi @Richard_Pawson, these system generated posts are created whenever anyone writes and shares a blog post. I’m hoping you’ll take the bait on one I’ve just written on coursework - I’m always interested in your opinion and experience!
@jdelasheras I really enjoyed your article - thanks for sharing. My Y13s were working through an exam question on OOP vs Procedural the other day so I’ll share the link with them.

Javier De Las Heras
16/05/2022 14:36

Thanks Pete. Really appreciated. I hope it helps your students as it is part of the A-Level syllabus and they need to know this and be able to discuss advantages and disadvantages.

Javier De Las Heras
16/05/2022 14:44

Hi Richard,
Thanks for your comments. It was not my intention to mislead teachers or students, but to help them both understand the differences between the two different paradigms as well as their advantages. This is part of the syllabus and it will be assessed. I agree with you that using either in isolation, or even suggesting it is simplistic and not what happens in industry.
I agree with your comment “The biggest benefits arise when you work consistently in a paradigm from highest-level analysis & design to lowest level implementation. Many people react against this sort of dictatorial approach, and favour ‘mixed paradigm’ approaches (often encapsulated in the phrase ‘horses for courses’ in my experience)”.

Thanks again.

Please login to post a comment