I still remember the first time I came in contact with the object oriented concepts. I was surfing on the msdn library (vs6) on a section called books and i stumble upon a book called visual basic 6 business objects. There were only a few chapters included but I found them amazing. I learnt and had been writing vb6 applications for a while back then but found the vocabulary foreign to me: “Business Object”, “Encapsulation”, “Polymorphism” and so on. It immediately hooked me up. The more I learnt, the more I wanted to start coding in this new and awesome way. But when it came to write code I found it so hard to start! The thing is that object oriented requires a new mindset and this change takes time.
I believe that the problem arises because almost every developer is first exposed to procedural programming and usually takes a lot of time to introduce them to object oriented programming. Also the way we are taught object oriented programming is often very poor. This 2 facts combined with a lot of the tutorials out there to learn object oriented languages are procedural exercises further enforces the procedural style into the pure minds of the knowledge seekers.
So what does procedural code looks like? There are so many ways and forms that instead of an example i’ll share some heuristics here.
- Your objects contain either just data or just methods
- Your objects expose data with the sole purpose to be used by someone else
- Almost all of your logic is on static methods
From procedural to object oriented
Procedural programming is a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, or functions (not to be confused with mathematical functions, but similar to those used in functional programming), simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program’s execution, including by other procedures or itself. Procedural programming languages include C, Go, Fortran, Pascal, Ada, and BASIC.
So the procedural thinking is all about procedures and the data that you pass to them. You start thinking what the variables are, how they look like (data structures) and what to do with it whereas an object oriented way gets you thinking who does what (responsibilities) and who works with who in order to complete a task (collaboration). The how (implementation) is relegated to a later stage. Instead of thinking on data and procedures, now you have objects that bundle data and procedures in order to do things.
Now comes the tricky part, most of the time you should expose only methods, not data (properties). If you’re familiar with an object oriented language (i.e. java, C#) go and try writing a program without the use of properties. Do not expose any data just for anyone else to use it. Ask for help not for data (encapsulation). This will naturally lead to objects that have data and the methods to manipulate that data. This is good. So instead of writing mailer.send(mail) now you’ll write mail.sendThrough(mailer). And mailer may have something that looks like mailer.send(recipient,sender,subject,body). This subtle change has a big impact on the code. Try it and stop writing pascal on Java 😉