Benefits and Limits of OOP

The gains are concrete and worth naming precisely. State becomes defensible: when only the owning class can change a field, invalid states stop being representable. Behaviour becomes reusable: a rule written once inside a class is available to every caller of that class. Callers become decoupled: they depend on a contract rather than on a procedure, so the implementation can be rewritten without touching them. And tests become easier, because a class that receives its collaborators instead of constructing them can be given fakes.

The costs are concrete too. Every concept becomes a file, and every indirection is another place to look when something fails. Object graphs make data flow harder to follow than a straight function call. Deep hierarchies mean a behaviour change ripples through parents and children. And construction graphs mean that creating one object can quietly pull in five others, which surprises people who came from a procedural background.

The tipping point is usually a problem with no interesting state and no second implementation. A value that flows through a pipeline and comes out transformed does not need a class. Nor does a helper that will never change. The style earns its cost when there is behaviour to protect, variation to absorb, or shared domain rules to enforce in one place.

That framing is the strongest interview answer: it shows you are applying the style rather than reciting it, and it gives the interviewer room to probe where you would draw the line yourself.

The main advantages for a project are reuse, maintainability and testability. Classes let a domain rule live in exactly one place, so a change to the rule is a change in one file rather than a hunt through every caller. Encapsulation and abstraction let you change the inside of a component without changing the outside, which is what keeps a large codebase changeable. Injecting collaborators rather than constructing them internally is what makes a class straightforward to unit test.

What you give up is simplicity at the point of use. Code written in an object-oriented style is longer, spread over more files, and indirect. Behaviour that used to be visible in one function is now spread across a graph of collaborating objects, so a beginner reading the code sees indirection before they see the logic. Performance also usually takes a small hit, since message passing and dynamic dispatch cost more than a direct call.

The trade is worth it for systems that live. For a script that runs once and is deleted, the ceremony is pure cost. For software that will be changed for years by people who did not write it, paying the cost up front is usually the cheaper option overall.