Encapsulation, abstraction, inheritance and polymorphism are the four pillars.
Encapsulation keeps an object's data with the code that changes it, reachable only through the object's methods.
Abstraction shows what an object does and hides how it does it.
Inheritance lets one class build on another.
Polymorphism lets one piece of code work with several types.
The four overlap. Encapsulation and abstraction are two views of the same boundary. One hides state, the other hides steps. Inheritance is only one route to polymorphism, and often not the best.
Treat them as tools, not goals. Applying all four to every class produces deep hierarchies and wrappers that add nothing. The payoff is that a change lands in one file instead of twenty, and a new case plugs in without touching old code.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
Encapsulation and abstraction sound alike. How do you tell them apart?Same boundary seen two ways. One hides an object's state, the other hides how a job gets done. Back each with a small example.
If inheritance often isn't the best route to polymorphism, what would you use instead, and why?Interfaces plus composition. Say what subclassing ties you to, like the parent's internals, and how holding an object lets you swap behavior.
Does putting a getter and setter on every field give you encapsulation?A strong answer says no. Public setters still let any caller change state. The class should guard its own rules and offer behavior instead.
How would you add a new payment type without editing the existing classes?Callers depend on an interface, the new type is a new class that implements it, and only the place that picks the implementation changes.
Where does applying the pillars everywhere make code worse? Give an example.Name a concrete case, such as a hierarchy several levels deep for one variant or a pass-through wrapper, and what it made harder to change.
What you can say
There are four pillars: encapsulation, abstraction, inheritance and polymorphism.
Encapsulation keeps an object's data with the code that changes it, so other code can only reach that data through the object's methods.
Abstraction shows what an object does and hides how, inheritance lets one class build on another, and polymorphism lets one piece of code work with several types.
They overlap, though, because encapsulation and abstraction are two views of the same boundary, one hiding state and the other hiding steps.
Inheritance is only one route to polymorphism, and often not the best, which is why I treat the four as tools, not goals.
Applied to every class, they give you deep hierarchies and wrappers that add nothing, so I use them where they let a change land in one file instead of twenty.
Weak answers to avoid
Recites the four names and stopsNaming them shows you memorized a list. Give one plain sentence per pillar and say what each one buys you when the code has to change.
Says encapsulation and abstraction are the sameCalling both "hiding" blurs them. Encapsulation hides state behind methods, abstraction hides how a job is done behind what it does.
Treats inheritance as the heart of OOPLeaning on deep hierarchies is a red flag. Say inheritance is one route to polymorphism and that interfaces with composition often fit better.
Says every class should use all fourTreating the pillars as goals produces deep hierarchies and wrappers that add nothing. Say you apply them where they keep a change in one place.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
