Object-Oriented Programming (OOP) is a common sight in pretty much all modern developer roles and it is defined with 4 pillars that hold its definition together.
The four pillars of object-oriented programming are:
Abstraction is defined as ‘the removal of details’ and this is a great way to think of it for coding. Simply put, when we abstract code we take the important details from and create an abstract version for our code.
A really easy way to think of this is when you make a template for something at home like a cookie cutter. The template contains all the information relevant to use to use it, and ignores the unnecessary stuff (like frostings or buttons).
Abstraction is not a template tool though, it is the principle of deciding what is relevant to capture for the business need, from properties (like name or age) to methods (like show current age).
We could do the same abstraction in several different projects and come out with a slightly different abstraction each time. This is because it always ultimately boils down to the business needs and capturing only the required details.
Once you have your abstraction, encapsulation is about only showing the relevant information to the end user. Some people say it’s about hiding details, but for me the hiding is a by-product and should never be the intention.
If you take the object example from earlier, they had a method called ‘show current age’. This is an example of an encapsulated method because the end user can call this and see the answer (let’s say 21 ;)). How this calculation happens and the logic it applies in order to return the result is ultimately hidden from the end user with only the relevant information shown to them.
Inheritance is probably the easiest concept to understand out of the four pillars. This is because the word is still used in everyday use and holds the same meaning so most people will intuitively apply that to their code.
Inheritance is when something is passed on. Typically we see it when a family member dies and their titles, property and wealth are inherited by their children.
In code, inheritance works the same way. You create a class (like our object example of a person) and you can then create a new class called Student that inherits from person and extends it. This allows you to have the best of both worlds, creating similar classes without duplicating the code. In this example our student will still have name and age but will also have any additional properties defined by the Student class.
Polymorphism is probably the hardest concept for people to grasp when it comes to the 4 pillars for exactly the opposite reason as Inheritance. If you try to break apart the word though you can get a feel for its meaning. Poly means ’many’ and morph is ‘shape’ so the polymorphism pillar is code that can respond to multiple types at runtime.
I’m almost ashamed to say that whilst googling, I found some good simple examples of this on Wikipedia.
Imagine you have a method for Add. If you add two numbers, it returns the sum. If you add to strings it concatenates them. The add method is overloaded based on type so that it can respond differently at runtime to different inputs.
So when do I use the pillars?
When you’re writing object-oriented code, the pillars should form the foundation of your coding style. Regardless of a particular design pattern or architecture that you’re following, the pillars form a firm foundation for SOLID code.
‘When’ is always subjective, but begin by abstracting your ideas into models and methods, inherit where appropriate and then encapsulate that logic into methods and only expose the relevant information to your end user (using polymorphism as necessary).
Remember – If you get stuck, ask for help! We all start somewhere and the sooner you have the foundations down, the quicker you will code amazing stuff. Have fun and keep going!