Structured Programming: The Basics

Introduction to Structured Programming
Programming is simply the act of giving a computer instructions for it to accomplish a specific task, while Structured Programming involves adding some structure to those instructions (code) to make it easily debuggable, maintainable, and understandable. That being said, imagine writing a program to cook a certain dish, say jollof rice. Many people would accomplish this task with different structures. Some might parboil the rice before cooking it in the tomato-based sauce, and others might just cook the rice directly in that sauce. No matter what method you use, we're still going to end up with a delicious pot of jollof rice (I hope). It's the same with programming. You can write some code with two different structures, and both of them will accomplish the same task. In this article, we are going to explore the most popular programming paradigms by pitting them against each other in a series of categories to see where each paradigm excels. Now, I'm not one for spoilers, but let me just say that one of these paradigms we are about to discuss can be considered the Swiss army knife of programming paradigms. Now let's get to it!
Let's get to know our competing paradigms
Procedural Programming: This paradigm breaks the program into smaller reusable chunks called modules or procedures, which accomplish specific tasks. You can think of this paradigm like cooking rice from the earlier analogy. Cooking jollof rice is a huge task that you will break down into smaller modules like washing the rice, cutting the onions, and frying some chicken. Once you have prepared all these "modules," you must put the dish together sequentially by following steps like washing the rice before cooking. You can also use some leftovers from the rice, like the fried chicken, in some other dishes.
Object-Oriented Programming: Just as its name suggests, object-oriented programming is all about objects. It takes a somewhat literal approach to coding, allowing you to treat your code like real-world objects with physical attributes and capabilities/behaviours. These objects are formed from a blueprint called a "class." Revisiting the jollof rice analogy, you can think of ingredients like your tomato puree and seasoning cubes as objects with distinct physical attributes and methods like adding flavor and color to the food. You don't know every ingredient your seasoning cube contains, and you don't need to know that to use it (encapsulation & abstraction). If you use the same tomato puree for some pasta, it will probably taste a bit like the rice (inheritance), and your tomato puree will come out differently if you cook it by boiling or frying (polymorphism).
Functional Programming: This programming paradigm makes use of functions a lot. You could even say functions are key here. It also applies a level of separation of concerns. Think back to our rice analogy, but this time, instead of cooking our rice in that tomato-based sauce, we decide to cook our rice alone and make a stew from the tomato-based sauce. We also serve our rice and stew on separate plates. For the rice, we use a specialised gadget called a rice cooker (higher-order function), and we cook it while the stew is cooking (parallel processing).
The paradigm showdown
What's the point of learning about all these paradigms if you don't know where they're useful? To that end, we are going to look at some categories you would usually consider before building a project and rank these paradigms in terms of how useful they are in each category.
Scalability: Most projects you build will require a lot of changes over time to add new features and, if done properly, work with larger amounts of data. So how do these paradigms rank in terms of letting you upscale your projects?
Rank 1: Object-Oriented Programming takes the cake here, making sufficient provisions for modularity, reusability, maintainability, and allowing you to manage complex relationships between components of your code.
Rank 2: With provisions for parallel processing and efficient handling of data transformations in its arsenal, Functional programming comes in second.
Rank 3: Procedural Programming comes in third. It is very straightforward in nature, but this straightforward nature can pose a lot of issues when it comes to maintainability and reusability.
Complexity: Imagine you are to write the code for a game like League of Legends. That is some pretty complex stuff right there, so which paradigm would be the best to use?
Rank 1: Making provisions for a very structured approach to building such a system, allowing objects to inherit behaviours, and having said objects react differently to the same method in different scenarios are only a few reasons why Object-Oriented Programming is ranked first.
Rank 2: Functional programming is a close second due to the sheer efficiency when it comes to handling large amounts of data.
Rank 3: Procedural Programming's simple approach to things puts it dead last in this case because it tends to produce code that is hard to read, understand, and maintain when dealing with complex tasks like this.
Performance: This one's a bit of a tricky category because other factors like the choice of programming language and specific use case heavily influence performance. That being said, all things being equal, the ranking should look something like this.
Rank 1: Procedural Programming doesn't really allow for low-level control over system resources, which makes it a good choice for performance-intensive tasks.
Rank 2: Object-Oriented Programming.
Rank 3: Functional programming.
Security: You're building a system and you need to conceal sensitive data. Let's see which paradigm's got you.
Rank 1: The encapsulation and abstraction that Object-Oriented Programming provides make it extremely secure.
Rank 2: Data in Functional Programming is normally immutable, which is a good security feature.
Rank 3: Procedural Programming doesn't really have any security-oriented features.
Conclusion
With this, it is safe to say that Object-Oriented Programming is a very versatile programming paradigm and is hardly lacking in any areas. This is why many programming languages support this paradigm, and it is so widely talked about. The other paradigms also seem to have areas where they shine. This leads to the fact that rather than using only one of these paradigms, you will mostly combine them when working on projects.
Call to Action
Now that you've learned a lot about structured programming, you could revisit old projects and try to identify what paradigm you have used just to strengthen your knowledge of these paradigms. It would also do you a lot of good to explore each of these paradigms and learn more about them. Make sure to apply this newfound knowledge to future projects. Catch you on the next one!
About the author
I am a computer science student and an aspiring data analyst. I write really helpful articles on computer science and data analysis topics. You should check out my blog
Comments
Join the discussionNo comments yet. Be the first to comment.




