# Polymorphism

ELI 5 example.

Bob is 5 year old Joey's uncle.

Whenever Bob comes over, Joey crawls onto Bob's lap, and Bob greets with "Hey Joey, my angel".

It's X-mas Eve. Uncle Bob visits Joey as Santa ðŸŽ….

Our cute little Joey wears a blissful smile ðŸ˜„ and jumps onto Santa's lap.

"Ho ho ho, Merry X-mas Joey" greets Santa.

Santa is Bob (Santa inherits from Bob) but Santa greets differently (overriding behavior) when he's Santa Clause.

## when I would use it

When you want to optionally handle differently in child classes.

## how it is used

Suppose that your site needs to process two payments transaction actions, both of which derive from the same parent and knows how to "processPayment".

1. PayPal
2. Credit Card

When your payment processor calls processPayment,

PayPal action will know how to contact PayPal and retrieve money,

and Credit Card action will know how to request Credit Card company for credits.

# Encapsulation

ELI 5 example.

Our Joey requested his mom for some pancakes ðŸ¥ž.

As Joey's served, he asks his Mom how she cooked it ðŸ¤”.

Mom placed her index finger on her lips and told him, "Shhh, it's a secret "ðŸ˜‰.

Joey got what he what he asked for (pancakes, the public data)

but Mom didn't reveal her recipe and prep steps (internal details).

## when I would use it

When you want to hide how your internal state/process is managed.

## how it is used

Suppose that your custom NPM library exposes a method to sort an array.

You didn't have time so you used the easiest sorting algorithm (Bubble Sort ðŸ˜²).

Later on, people reported that it was too slow so you implemented it with a quicksort.

If you have not exposed any logic on how the sorting is implemented,

library users wouldn't have to change their code.

I like this. You win. ðŸŽ‰ðŸŽ‰ðŸŽ‰

Thank you for providing an opportunity for let me mull over this ðŸ˜Ž.

I love answering these threads so much. It usually forces me to google those last few things on a topic I never really understood.

Yes, and also able to find gaps in our knowledge.

My gap -> Abstraction vs Encapsulation.

Okay I am a bit confused between Encapsulation and Abstraction. I thought Abstraction was about hiding implementation and Encapsulation was about hiding data. I would appreciate it if you could explain Abstraction as well :D

Encapsulation is only if you want or not expose something. It could be only one thing no matters what it do. For example: you have a class to calculate a salary with two methods: GetMonthlyWage() and GetWeeklyWage(). Inside the first one you only call GetWeeklyWage() and multiply by 4. Every one could call the first method, then it's public. But you decide if you want the others could see and call GetWeeklyWage() or not. If not, you make it private. The abstraction could use encapsulation, but it is about how a method can be implemented. An abstract class is a template and each implementation of the class (concrete class) could implementate a different way to do something. No matters if it is public or private (or other access modifyer). Then, for contractor employees you could implementate the GetMonthlyWage() giving a bonus and for external workers you could implementate GetMonthlyWage() without the bonus.

Okay I am a bit confused between Encapsulation and Abstraction. I thought Abstraction was about hiding implementation and Encapsulation was about hiding data. I would appreciate it if you could explain Abstraction as well :D

In a very general sense, all code is abstraction :)

What people mean when they talk about Abstraction is really about turning some code into a more generalized concept. Usually this goes hand in hand with encapsulation, but the two aren't the same and they can be used separately.

If we think about what the word Abstract means, it means "apart from concrete existence". Which is a fancy way of saying it's about describing a real thing in your own words, to make thinking about that real thing easier.

If you're writing some code and you feel like it gets too much to keep track of you might think to yourself "I will make a function to gather up these lines". So you turn your four or five lines of code into a function called user_login() and call it instead of writing those five lines out. user_login() is now an abstraction, instead of the concrete (the five lines you need to execute to login a user) you wrote the abstract concept user_login().

It's not about hiding implementation (anyone can go look at user_login() after all), but about simplifying and generalizing the code in front of you.

Encapsulation is only if you want or not expose something. It could be only one thing no matters what it do. For example: you have a class to calculate a salary with two methods: GetMonthlyWage() and GetWeeklyWage(). Inside the first one you only call GetWeeklyWage() and multiply by 4. Every one could call the first method, then it's public. But you decide if you want the others could see and call GetWeeklyWage() or not. If not, you make it private. The abstraction could use encapsulation, but it is about how a method can be implemented. An abstract class is a template and each implementation of the class (concrete class) could implementate a different way to do something. No matters if it is public or private (or other access modifyer). Then, for contractor employees you could implementate the GetMonthlyWage() giving a bonus and for external workers you could implementate GetMonthlyWage() without the bonus.

I am confused about the difference.

I will do some research and get back later ðŸ˜Ž

Abstraction:

Joey's Mom: "Joey, what do you want for breakfast?"
Joey: "I dunno, Mommy... I feel like something sweet and crunchy."
(Abstract class SweetAndCrunchy)

Joey's Mom: "Do you want granola with maple syrup?"
(GranolaMapleSyrup implements SweetAndCrunchy)

-- Edit --

As Dinesh Patra noticed, technically, this should be either:
(Abstract class SweetAndCrunchy)
(GranolaMapleSyrup extends SweetAndCrunchy)

or:

(Interface SweetAndCrunchy)
(GranolaMapleSyrup implements SweetAndCrunchy)

I would like to focus here on the Interface version.
"Abstraction" is a concept. The concept of abstraction in OOP is accomplished at several levels. The topmost level of abstraction is the Interface. An Interface declares one or more methods that should be implemented by the classes that implement that interface.
The next level of abstraction is the Abstract Class. This type of class can't be instantiated: it has to be extended by a concrete (normal) class. The problem with using abstract classes in the current discussion is that an abstract class can in fact already provide an implementation, which makes matters all the more confusing for people trying to learn OOP, so here I would like to stick to the concept of abstraction and forget about specifics.

Ace! Thanks Carlos ðŸ˜„

Thanks Carlos. But I got a doubt.
As per my understanding, We can implement on interface and inherit from abstract classes right. So SweetAndCrunchy is an interface not abstract class.
Please correct me if my understanding is wrong.

Yes, you are right: the "implements" implies SweetAndCrunchy is an Interface.
But we were talking about the concept of abstraction, versus the concept of encapsulation.
"Abstraction" means you are talking about the idea of a thing, and not the concrete thing itself. "Encapsulation" means you can't change the inner workings of the thing.

Abstraction is accomplished at several levels. An Interface is the most abstract level of abstraction there is. To keep it simple, I wouldn't go now into abstract classes because those have very specific technicalities.

Thank you for the clarity explanation.

Code of Conduct Report abuse