Have you ever noticed how the same cliche questions are asked at job interviews over and over?
I’m sure you understand what I mean.
As an example:
What do you want to be in five years?
or, even worse, what do you consider your greatest flaw?
Give me a break, please.
Answering this question is one of my major flaws!
Anyway, that’s not my point.
As insignificant as these questions may appear, they are significant because they reveal information about you. Your current state of mind, attitude, and viewpoint.
You should be cautious when responding, as you may reveal something you later regret.
Today I’d like to discuss a similar type of programming question:
I’ve been on both sides of the debate. It’s one of those topics that gets asked so frequently that you can’t afford to be ignorant.
Junior and entry-level developers are usually required to respond. Because it allows the interviewer to quickly convey three messages:
1)Did the candidate plan ahead of time for this interview?
If you get an answer right away, it demonstrates a serious approach.
2) Has the candidate completed the tutorial stage?
Understanding the Object Oriented Programming Principles (OOP) demonstrates that you’ve progressed beyond simply copying and pasting from tutorials — you already see things from a higher level.
3) Is the candidate’s comprehension deep or superficial?
The level of competence on this question is frequently equal to the level of competence on the majority of other subjects.
Encapsulation, abstraction, inheritance, and polymorphism are the four Object Oriented Programming Principles.
These words may be frightening to a junior developer. And Wikipedia’s complex, overly long explanations can sometimes add to the confusion.
That is why I want to provide a concise, concise, and clear explanation for each of these concepts.
It may sound like something you’d tell a child, but I’d love to hear these responses when I conduct an interview.
1. Encapsulation
Ok so let’s start with the first one of the four object oriented programming principles
Assume we have a program. It consists of a few logically distinct objects that communicate with one another according to the program’s defined rules.
Encapsulation is achieved when each object within a class keeps its state private. This state is not accessible to other objects. Instead, they can only invoke a set of public functions known as methods.
As a result, the object manages its own state through methods, and no other class can touch it unless explicitly permitted. You should use the provided methods to communicate with the object. However, you cannot change the state (by default).
Assume we’re creating a miniature Sims game. There are people present, as well as a cat. They converse with one another. Encapsulation is desired, so we encapsulate all “cat” logic in a Cat class. It could look like this:
In this case, the cat’s “state” refers to the private variables mood, hunger, and energy.
It also includes a private method meow (). It can call it whenever it wants; the other classes have no control over when the cat meows. The public methods sleep(), play(), and feed() define what they can do.
Each of them alters the internal state in some way and may invoke meow(). As a result, the link between the private state and public methods is formed. This is called encapsulation.
2. Abstraction
Abstraction can be viewed as a natural extension of encapsulation.
Programs in object-oriented design are frequently extremely large. And separate objects frequently communicate with one another.
So maintaining such a large codebase for years — with changes along the way — is difficult.
Abstraction is a concept that seeks to alleviate this issue.
Because abstraction is used, each object should only expose a high-level mechanism for use.
Internal implementation details should be concealed by this mechanism. It should only show operations that are relevant to the other objects.
Consider a coffee machine. It does a lot of things and makes strange noises under the hood. However, all you have to do is add coffee and press a button.
This mechanism should ideally be simple to use and rarely change over time. Consider it a small set of public methods that any other class can call without “understanding” how they work.
Another example of abstraction in action?
Consider how you use your phone:
You use only a few buttons to interact with your phone. What exactly is going on under the hood? You don’t need to know because implementation details are concealed. You only need to know a few simple actions.
Implementation changes, such as a software update, rarely have an impact on the abstraction you use.
3. Inheritance
Okay, we’ve seen how encapsulation and abstraction can aid in the development and maintenance of a large codebase.
But do you know what else is a common issue in OOP design?
Objects are frequently very similar. They have similar logic. However, they are not identical. Ugh…
So, how do we reuse the common logic while separating the unique logic into its own class? Inheritance is one method for accomplishing this.
It means that you derive a (child) class from another (parent) class. We can create a hierarchy this way.
The child class reuses all of the parent class’s fields and methods (common part) and can implement its own (unique part).
As an example:
We can use this class hierarchy if our program needs to manage not only public and private teachers, but also other types of people such as students.
Each class adds only what is required while reusing common logic with the parent classes.
4. Polymorphism
We’ve arrived at the most difficult word! In Greek, polymorphism means “many shapes.”
So we are already aware of the power of inheritance and happily employ it. But then there’s this issue.
Assume we have a parent class and several child classes that derive from it. Sometimes we want to use a collection, such as a list, that contains a mix of all of these classes. Or we have a method for the parent class that we’d like to use for the children as well.
Polymorphism can be used to solve this problem.
Simply mentioned, polymorphism allows you to utilise a class precisely like its parent, avoiding type confusion. However, each child class retains its own methods.
This is commonly accomplished by specifying a (parent) interface that will be reused. It describes a variety of common procedures. The child classes then implement their own versions of these methods.
When a collection (such as a list) or a method expects an instance of the parent (where common methods are defined), the language evaluates the appropriate implementation of the common method — regardless of which child is supplied.
Consider the following drawing of geometric figure implementation. They use the same interface to calculate surface area and perimeter:
By inheriting the parent Figure Interface from these three figures, you may generate a list of mixed triangles, circles, and rectangles. And handle them as if they are the same type of item.
The right procedure is then located and run if this list attempts to calculate the surface of an element. If the element is a triangle, the triangle’s CalculateSurface() function is invoked. If it’s a circle, the CalculateSurface() function is called. And so forth.
You don’t have to write a function that operates on a figure by utilising its parameter three times — once for a triangle, once for a circle, and once for a rectangle.
You only need to define it once and then accept a Figure as an argument. It doesn’t matter whether you pass a triangle, circle, or rectangle as long as they implement CalculateParamter().
I hope this was helpful. These similar reasons can be used directly in job interviews.
If you have any further questions, please leave them in the comments section below.
What comes next?
So now I hope object oriented programming principles with examples have helped you to clear out most of your doubts.
It’s fantastic to be prepared to answer one of the all-time interview questions, but occasionally you don’t get called in.
Following that, I’ll discuss what employers look for in a junior developer and how to stand out from the pack + you can subscribe to my newsletter to grab my introduction to object oriented programming concepts pdf.
Keep an eye out(Follow me).
Wait, buy me coffee before you go and share this on Twitter too ok!
Bye
