The Four Pillars of Object Oriented Programming

OOP is a programming paradigm that computer programmers must encounter in their life. This article assumes you are already familiar with Class & Objects. To enhance your OOP understanding four pillars are worth discussing. So, let’s jump into the details:

Inheritance

The very first pillar is inheritance & it’s totally connected with the real world. As we know, if a father has property then his son will inherit it. And yes every child is going to inherit it. In programming, inheritance complies with the same concept. Let’s see in the code:

	class Father {

		public $name = "Sr. John Doe";

		public function totalProperty() {
			return "USD 1000000";
		}
	}

	class Son extends Father {
		public $name = "John Doe";
	}

	$son = new Son();
	echo "{$son->name} inherit {$son->totalProperty()}"; 

Output: John Doe inherit USD 1000000

Here, we can see the Son class extends the Father class & a $son object. Though the Son class doesn’t contains the totalProperty() method still we can call it by using the son object, this is because of inheritance that has been done using the keyword extends! So if a class extends to another class then we call this class a child class & the main class (Father) is called a parent class. In a simple sense, this is inheritance. The child class will inherit all the properties & methods from the parent class except private data.

Polymorphism

At its base, polymorphism refers to many forms, but that’s not very helpful unless you understand it in the context of OOP. The real value of polymorphism is that objects with the same interface can be called to do different things. In a large complex structure (a great big program), additions and changes can blow the hinges off your program unless it has a common interface (from a parent class or interface). For example, the following program has two classes that share a common interface. The implementations of the interface are quite different: 

	interface ISpeed
	{
		public function speed();
	}

	class Jet implements ISpeed 
	{
		public function speed(){
			return 2500;
		}
	}

	class Car
	{
		public function speed() {
			return 100 + 50;
		}
	}

	$jet = new Jet();
	echo "Jet speed is {$jet->speed()} <br>";

	$car = new Car();
	echo "Car speed is {$car->speed()}";

Output: Jet speed is 2500
Car speed is 150

The two implementations of the ISpeed interface by the Jet and Car classes are very different. However, when making changes or additions within a given structure of a program, I can request or use the interface methods without having to worry about whether my program will crash or not.

One Name with Many Implementations

The easiest way to understand polymorphism is in the different implementations of an interface. The Jet class simply implements each method to return a primitive value, and the Car class makes an addition and then returns a value. Both used the same interface.

Encapsulation

In the previous two examples of inheritance & polymorphism, we have created classes & keep properties and methods inside them. This is basically called encapsulation! Yeah, as simple as it sounds. The term encapsulation simply makes things compact and hides unnecessary details. By using encapsulation, we can set visibility to expose information as per need & making staff secure. If we didn’t wrap properties & methods then it could be accessible from anywhere & it would be unorganized & unmanageable.

Class Abstraction

Abstraction in the real world

I’m a coffee addict. So, when I wake up in the morning, I go into my kitchen, switch on the coffee machine and make coffee. Sounds familiar?

Making coffee with a coffee machine is a good example of abstraction.

You need to know how to use your coffee machine to make coffee. You need to provide water and coffee beans, switch them on, and select the kind of coffee you want to get.

The thing you don’t need to know is how the coffee machine is working internally to brew a fresh cup of delicious coffee. You don’t need to know the ideal temperature of the water or the amount of ground coffee you need to use.

Someone else worried about that and created a coffee machine that now acts as an abstraction and hides all these details. You just interact with a simple interface that doesn’t require any knowledge about the internal implementation.

Abstraction in OOP

Objects in an OOP language provide an abstraction that hides the internal implementation details. Similar to the coffee machine in your kitchen, you just need to know which methods of the object are available to call and which input parameters are needed to trigger a specific operation. But you don’t need to understand how this method is implemented and which kinds of actions it has to perform to create the expected result.

	abstract class CoffeeMachine {

		// Child class must have to follow method signature
		public abstract function getBeans(): string;

		// Child class must have to follow method signature
		public abstract function getMilk(): string;

		// Making Coffee
		public function makeCoffee() {
			$beans = $this->getBeans();
			$milk  = $this->getMilk();
			return 'Hot Cappucino!!!';
		}
	}

	class CoffeeApp extends CoffeeMachine {

		private $beans;
		private $milk;

		public function __construct($beans, $milk) {
			$this->beans = $beans;
			$this->milk = $milk;
		}

		public function getBeans(): string {
			return $this->beans;
		}

		public function getMilk(): string {
			return $this->milk;
		}
	}

	// Client don't need to know coffee is getting ready
	// They just need to pass beans & milk
	$coffeeApp = new CoffeeApp('beans', 'milk');
	echo $coffeeApp->makeCoffee();

Output: Hot Cappucino!!!

Yeah, as a coffee lover, we do care about the output 😀 not what is happening inside the machine!