RENOR & Partners è una società di consulenza d'impresa con alti standard qualitativi e con i prezzi più bassi del mercato.
RENOR & Partners S.r.l.
Via Cicerone, 15 - Ariccia (RM)
info@renor.it
CeliachIA - No Gluten App
- The Hybrid SocialProgramming: from procedural to OOP
Programming: from procedural to OOP
This post is also available in:
Italiano (Italian)
There are many people who would like to learn how to program for the Web but don’t know where to start. Some rely on books, some rely on online courses but what I keep hearing is always the same phrase: “I started studying a Backend language on an online course but object-oriented programming is too difficult.”
Indeed, almost every textbook I have read in life on the OOP paradigm complicates a concept that I would characterize as the natural evolution of procedural and functional programming.
Why make it complicated?
Because in my opinion, all books and all courses necessarily want to bring examples comparing object-oriented programming to real life. In fact, people who have learned to program procedurally up to that point have only seen examples in the development world: what is a variable, what is an array, how to cycle an array, how to write a condition, how to make a flowchart, how to write a function; therefore, I don’t think they are used to picking up examples in the real world at this stage, but after they understand what the object-oriented paradigm implies in computing. It is a method of thinking about code that becomes almost necessary when moving from a small project to a larger project or one that will need to be maintained and extended in the future. Only when you are clear about these basics will it be possible to bring examples into real life.
Complicating discourages
By complicating things in this way, new “adepts” to the programming world become discouraged. The result is that some of them drop their interest in programming, others remain stuck in procedural or functional programming without knowing that from functional programming to OOP is really a very short step.
Those who develop procedural projects can create headaches for those who will have to put their hands back on the code
The object-oriented paradigm is not just a “different way of organizing code” but provides rules and a modus operandi such that those who will have to get their hands on code developed by someone else will be able to do so without splitting their heads for too long searching for “what does what.”
Also, in object-oriented programming, one should never underestimate the power of the UML.
In essence, object-oriented programming provides all the best practices that a good developer should put in place to make code that is easily readable, structured as it should be, easily maintainable, and scalable.
Speaking of scalability
Not only does the object-oriented paradigm channel the developer into virtuous development, but it also allows the developer to take advantage of a whole host of ready-made and easily integrated tools. Git Hub is teeming with ready-implemented and easily integrated Classes, mostly through Composer, which provide a way to save so much time in development. Classes exist for just about anything: generating a PDF, sending eMail, integrating with eBay and Amazon APIs for automating eCommerce projects, generating QR Codes and Bar Codes, comparing images, resizing images, compression, etc. etc.
These tools are always written with an object-oriented paradigm, and to take advantage of them and, in some cases, readjust them to our needs, it is necessary to be familiar with this philosophy of writing code.
When is it difficult to climb?
Several times I have had to rehash projects written procedurally… I had to literally lose days just to figure out how the code was organized, having to read files of tens of thousands of lines of code. It becomes very difficult to modify even a very trivial function because you have to go searching through the thousands of lines for that portion of code that is responsible for putting that action into effect, stand there for hours debugging… Hell.
In object-oriented projects this would have been disarmingly trivial!
How does object-oriented programming work?
We have been circling the topic for minutes but still have not given a definition that is easily understood.
To learn object-oriented programming there is no other way than to learn first procedural programming, then functional programming and finally object-oriented programming, because one is the natural evolution of the other.
Programming means being able to analyze a big problem, break it down into smaller problems and find solutions to each of these smaller problems and then put the pieces back together to solve the main problem. To do this we use functions.
The transition from procedural to functional programming is quite simple: functions are binders of procedural code that specialize in solving a small problem. E.g. write a program that deals with searching for a string within another string; if it finds it return positive outcome otherwise negative. This program I can write within a function. Functions in programming are exactly like mathematical functions: you pass one or more variables as input after which the function processes them and returns a result, or if we want to say it in a more properly mathematical way. Given a function for every element in the domain of the function corresponds to one in the codomain. In programming, functions have input parameters that are processed and an output value is returned.
This solves a small problem derived from the main problem, and I can continue to solve small problems with other functions and then put them together to solve the main problem.
At the point when I have finished preparing all these functions, I can evaluate which ones are solving a class of problems. For example, let’s say we need to calculate the total of n outstanding invoices from a company and then have to email this total to the customer who owes us for them.
First problem: getting all the data from a database
Second problem: examining invoices
Third problem: adding up the unpaid bills.
Fourth problem: email the total amount to the customer for payment
How would we solve it with functional programming?
First problem:
- I write a function that makes the connection to the database
- I write a function that does a SELECT query in the database to retrieve the data
- I put them into an array
Second problem:
- I write a function that loops my array
- I write a function that downloads all the invoices to me.
- I write a function that inserts unpaid bills into another array
Third problem:
- I write a function that loops the array and sums the total invoices to me in a return variable
Fourth problem:
- I write a function that sends an email to the customer by passing them the value of the variable containing the invoice total
- I verify the correct sending of the email
As you can see, we solved the main problem “Calculate the total of n outstanding invoices of a company and email the total to the customer for payment” by using functions that solve subcategories of the main problem by simply putting them together in an orderly way.
How to bring this into an OOP perspective?
One must break down the actors involved to understand which Problem Classes these belong to…. For example, Database Connection is a Problem Class that differs from Invoices, so Invoices might be another Problem Class, just asSending Mail is further another Problem Class than Database Connection and Sending Mail.
We have therefore identified Classes that are nothing more than binders of functions, which, within them, take on the name “Methods.”
For this problem we will have the Connection Class for connecting to the database, the Invoices Classfor all the functions that satisfy the requirement to solve invoice-related subproblems, and the Mail Classthat contains the methods related to sending e-mail. Each class collects the methods (or if we still want to use the term “functions”) related to their problem-solving class.
Theobject that is instantiated (created) by the Class, is nothing more than a container of the methods that implements the Class (and of properties that are nothing more than the variables in play within the Class) that can be used to solve the main problem.
Of course this is one approach, but everyone could draw their own conclusions about the actors as they see fit and there would be no right and wrong version. For example, a developer could have integrated the methods for sending Mail within the Invoice Class since they relate to sending Mail containing billing data. That would have been reasoning that I disagree with but not incorrect.
Why using the object-oriented paradigm makes the code easier to maintain?
Simple! Because if I were to be asked tomorrow to integrate the average of the total invoices as well, all I would have to do is add a method to the Invoices Class that would take care of calculating the average value of that Customer’s invoices, without having to stand around looking in a single file for the part of the code that deals with the invoice.
The important thing to do when programming in objects is therefore to figure out what problems are involved, structure a diagram called the UML, and collect within each class all the microproblem-solving methods assigned to that Problem Class. Once the argument runs smoothly on paper you can start writing comments (a best practice that you can read about in this article) and lastly lay out the code. The task will become really trivial because the bulk of the work was done first with pen and paper.
Of course, this is not a course in OOP programming, the rules of object-oriented programming are many and must be understood in full: daughter class inheritance, abstract classes, interfaces, traits, etc., but once you get into the mindset of “What is a Class” and “Why move to object-oriented programming” it will be just a matter of studying these rules and applying them as you program and continue to program more and more. You will realize, once you understand it, the conceptual ease and how it really comes in handy for organizing code according to rules that can be easily interpreted even by another person who will have to redo your code.
As you have seen object-oriented programming is much simpler than people say, it is by no means an abstract and terrible concept that creates blocks for people who want to learn programming… It’s all about taking it the right way without standing there talking about Houses, Cars and Motorcycles (this is the most cited example), Palaces, Recipes, and you name it.
