OOPs Interview Questions

"The four are encapsulation, abstraction, inheritance and polymorphism. Encapsulation is a bank account class where the balance is private and the only way to change it is deposit or withdraw, which check the rules. Abstraction is a car's pedals: I press the brake without knowing whether it's disc or drum brakes underneath. In code, that's a PaymentService with a pay method that hides which provider it calls. Inheritance is a SavingsAccount that reuses everything in Account and adds interest. Polymorphism is having a list of shapes and calling area on each one: a circle and a square each run their own version, and the loop doesn't care which is which. The way I remember it, encapsulation protects the data, abstraction hides complexity, inheritance reuses code, and polymorphism lets one piece of code work with many types."

"A class is the definition. It says every Student has a name and a roll number and can do things like enroll in a course. An object is one actual student built from that definition, with its own values. If I create two Student objects, each has its own name and roll number, but they share the same method code; methods aren't copied into every object. In Java or C#, when I write new Student, the object is allocated on the heap and my variable only holds a reference to it, so assigning that variable to another one gives two references to the same object, not a copy. C++ also lets me create an object directly on the stack. So the class exists once, and there can be zero, one or a million objects of it at run time."

"I think of abstraction as a design decision about what to show, and encapsulation as the mechanism that protects what's hidden. Abstraction is choosing that a Notifier has one method, send, and callers never learn whether it goes by email or text message. Encapsulation is inside a class: the fields are private and every change goes through a method that keeps the object valid, like a withdraw method that refuses to take the balance below zero. You can have one without the other. A class with all public fields and one simple method has an abstraction but no encapsulation, because anyone can reach in and break it. So abstraction answers what does this thing do, and encapsulation answers who is allowed to touch its insides."

"A constructor runs exactly once, when the object is created, and its job is to make the object valid from the first moment. If a BankAccount must always have an owner, I take the owner in the constructor, so there's no way to get an account without one. Unlike a normal method, in Java, C# or C++ it has the same name as the class and no return type, and I can't call it again on an existing object. I can overload it, say one version with just a name and another with a name and an opening balance, and have the shorter one call the longer one so the setup logic lives in one place. If I don't write any constructor, the compiler gives me a default one with no arguments, but as soon as I write one that takes arguments, that free default goes away. In Python the closest thing is __init__, which sets up an object that's already been created."

"Access modifiers control who can see and use a field or method. Private means only the class itself, protected adds subclasses, and in Java the same package too, and public means anyone. Languages add their own extras, like package-level access in Java or internal in C#, and Python only has naming conventions with underscores that aren't enforced. My rule is to start everything private and open it up only when there's a real need. Everything public is a promise: once other code depends on it, changing it breaks them. Protected is a promise too, to every subclass anyone ever writes, so I use it less than people expect. Fields stay private almost always, and I expose behaviour through methods that keep the object valid, rather than handing out raw access to the data."

"An instance field belongs to each object, so two orders have their own totals. A static field belongs to the class, so there's one copy shared by every object, and a static method runs without any particular object, which means it can't touch instance fields directly. I make something static when it genuinely doesn't depend on an object: constants, pure helpers like a function that converts units, or a named factory method like fromJson. The trouble starts with mutable static state. It's really a global variable: every thread shares it, one test can leave it dirty for the next, and code that calls a static method can't easily be given a fake version in tests. Also, in languages like Java, static methods aren't overridden polymorphically. So I keep statics stateless and pass real dependencies in as objects."

"In a logging helper I wrote, I had log with just a message and log with a message and an exception. That's overloading: same name, different parameters, and the compiler picks which one to call from the arguments I pass, so it's decided at compile time. For overriding, I had a base Report class with a render method, and PdfReport and CsvReport each overrode it. The code held a Report reference and called render, and which version ran depended on the actual object at run time. That's dynamic dispatch, the heart of runtime polymorphism. One trap: changing only the return type doesn't make a valid overload. Also, Python doesn't overload by signature at all; a second method with the same name simply replaces the first, so there I'd use default arguments instead."

"The smell is code like if channel equals email, do this; else if sms, do that; and the same chain copied into three other functions. Every new channel means editing all of them, and missing one is a bug. With polymorphism I define a common type, say a Notifier with a send method, and write one class per channel. The calling code just loops over notifiers and calls send; it never asks what type it has. Each class carries its own behaviour, so adding push notifications is one new class and nothing else changes. I'd still keep a single place, like a factory, that turns a config value into the right object, because some code has to make that choice once. But it's one place, not scattered everywhere."

"I ask what I'm modelling. If I have a family of closely related types that share real state and code, like several report types that all have a title, an author and the same header logic, an abstract base class fits. It can hold fields, a constructor and finished methods, and leave just one or two abstract ones for each subclass. If instead I'm describing a capability that very different types might have, like being exportable or comparable, that's an interface. A class can implement several interfaces but usually extend only one base class, so interfaces keep my options open. Modern languages blur this a bit with default methods, but an interface still can't hold per-object state. In practice I often use both: callers depend on the interface, and an abstract class gives implementers a head start."

"Picture class A at the top, B and C both inheriting from it, and D inheriting from both B and C. That's the diamond. If B and C both override a method from A, which one does D get? And does D contain one copy of A's fields or two? Languages handle it differently. Java and C# only allow one base class, so the state problem can't happen; you can implement many interfaces, and in Java if two interfaces give conflicting default methods, the class has to override it and choose. C++ allows it; by default D really does get two copies of A, and you use virtual inheritance to share one. Python allows it and uses a fixed method resolution order so every class appears once and lookups are predictable. In my own designs, if I hit a diamond I usually take it as a hint to use composition instead."

"The principle says a class shouldn't be forced to depend on methods it doesn't use. The classic smell is an interface like Machine with print, scan and fax. A cheap home printer has to implement all three, so scan and fax end up throwing not supported, and anyone calling fax on a Machine gets a surprise at run time. I'd split it into Printer, Scanner and Fax, each with its own methods. The office machine implements all three, the basic printer implements only Printer, and the print queue depends only on Printer. That makes each dependency honest, and changes to fax don't force recompiling or retesting code that only prints. I cut interfaces by who uses them, not by guessing, so I don't end up with a hundred one-method interfaces either."

"The principle says a class should have one reason to change. Take an Invoice class that calculates totals and tax, renders itself as a PDF, and emails itself to the customer. Three different people could ask for changes there: finance changes the tax rules, the design team changes the layout, and ops switches the email provider. Every one of those edits touches the same class and risks breaking the others. I'd keep Invoice for the data and the calculation rules, move PDF output to an InvoiceRenderer, and sending to an InvoiceMailer. Now a layout change can't break tax maths, and each piece is easy to test alone. It doesn't mean one method per class; a class can have many methods as long as they serve the same purpose."

"It means that when a new requirement arrives, I should be able to add new code rather than reopen classes that are already tested and working. Say I have a report exporter with a switch for CSV and JSON. Every new format means editing that switch and retesting the whole thing. Instead I define an Exporter interface with an export method, and CSV and JSON are two classes behind it. When someone asks for Excel, I write an ExcelExporter and register it; the calling code and the existing exporters don't change at all. So it's open because new formats plug in, and closed because the core isn't touched. I don't do this for everything on day one, though. I usually wait until a second or third variation shows up, so I know which part actually changes."

"Liskov says anywhere the code expects a Rectangle, I should be able to pass a subclass and nothing should break. In maths a square is a rectangle, so it feels natural to inherit. But a mutable Rectangle promises that setting the width leaves the height alone. A Square must keep both sides equal, so its setters change both. Now a function that sets width to five and height to four and expects an area of twenty gets sixteen from a square. The code compiles fine, every signature matches, and it's still wrong, because the subclass broke the behaviour the parent promised. The fix is to stop forcing the relationship: make them siblings under a read-only Shape with an area method, or make them immutable so there are no setters to break. The lesson is that is-a in real life doesn't guarantee is-a in code."

"Dependency inversion says my business logic shouldn't depend on low-level details like a specific database or payment provider. Both should depend on an abstraction, and that abstraction is shaped by what the business logic needs. So an OrderService depends on a PaymentGateway interface that the order module defines, and the concrete provider class implements it. The arrow that used to point from orders down to the provider now points from the provider up to the interface; that's the inversion. Dependency injection is a technique: instead of the OrderService creating its own gateway with new, someone passes one into its constructor. Injection makes the principle easy to apply, but they aren't the same. I can inject a concrete provider class and still be tightly bound to it, and I can follow the principle with a simple factory and no framework at all."

"It means that when I want to reuse behaviour, my first choice is to have an object hold another object and delegate to it, rather than extend its class. Inheritance couples a subclass to the parent's implementation, so a change in the parent can quietly break every child, and the behaviour is fixed when I write the class. A well-known case is Java's own Stack class, which extends Vector, so a stack lets you insert into the middle, which no stack should allow. Holding a list inside and exposing only push and pop would have been right. Another sign is class explosion: FlyingDuck, SwimmingDuck, FlyingSwimmingDuck. With composition I give a duck a fly behaviour and a swim behaviour and can swap them at run time. Inheritance is still fine when the child truly is a kind of parent and can replace it anywhere."

"Cohesion is about what's inside a class: do all its fields and methods serve one purpose? A ShoppingCart that adds items, removes them and totals them is cohesive. If it also sends marketing emails, cohesion drops. Coupling is about the links between classes: how much one knows about another's internals. If my checkout code reaches into the cart's private list and the product's pricing fields, it's tightly coupled, and changing either one breaks checkout. We want high cohesion because a focused class is easier to understand and test, and low coupling because then a change in one class stays inside it instead of rippling across the codebase. In practice I lower coupling by talking through small interfaces and asking objects to do things rather than pulling their data out."

"All three are has-a relationships; the difference is ownership and lifetime. Association is the loosest: a Doctor treats Patients, a Teacher teaches Students. They know about each other, but neither owns the other. Aggregation is a whole-part link where the part can exist on its own: a Team has Players, but if the team is dissolved, the players still exist and can join another team. Composition is strong ownership: an Order has OrderLines, and a line makes no sense without its order. If the order is deleted, its lines go with it, and nobody else holds them. In UML aggregation is a hollow diamond and composition a filled one. In code, it shows up in who creates the part, whether it's shared, and what gets deleted together."

"A singleton guarantees one instance and gives everyone a global way to reach it. Having only one of something is often fine: one connection pool, one config loaded at startup. The trouble is the global access. Any class can grab it without saying so in its constructor, so dependencies are hidden. If it holds mutable state, it's a global variable in disguise, shared by every thread and every test. And because callers fetch it themselves, I can't easily swap in a fake for a unit test. So what I usually do is create one instance at startup and pass it to the classes that need it. I still get one instance, but the dependency is visible and replaceable. I'd only use a classic singleton for something that holds no business state, like a logger, where those costs barely matter."

"A factory puts the decision about which class to create in one place. Say I read a file and the extension decides whether I need a CsvParser, a JsonParser or an XmlParser. Without a factory, that if-else ends up in every caller, and each caller now depends on all three classes. With a ParserFactory, callers ask for a parser for this file and get back something of type Parser; they never see the concrete classes. It also helps when building an object takes several steps or needs config the caller shouldn't know about. But if there's only one implementation and the constructor takes two simple arguments, a factory is just extra code to read. I'd call new directly and add the factory the day a second variation actually appears."

"Strategy is for when one step of a process has several interchangeable versions. At checkout, the discount rule varies: none, a seasonal cut, a member rate. Instead of an if-else inside Checkout, I define a DiscountRule interface with one apply method and write each rule as its own small class. Checkout takes a rule in its constructor and just calls apply; it has no idea which rule it has. Adding a new promotion later means writing one new class and choosing it where Checkout is created, usually from config. Checkout and the existing rules don't change, and each rule can be unit tested alone. In languages with first-class functions I'd often just pass a function, which is the same idea with less code."

"A subject, say an Order, keeps a list of observers. When its status changes it loops through the list and calls each one's update method. The email sender, the stock updater and the analytics tracker all subscribe, and the Order doesn't know any of them exist, so adding a new reaction is just one more subscriber. In a long-running app, the classic problem is forgetting to unsubscribe. The subject still holds a reference, so an old screen or object can't be garbage collected and keeps receiving events: a memory leak plus strange behaviour. Others: observers quietly relying on notification order, one observer throwing and stopping the rest from being called, and chains where one update triggers another until nobody can trace why something happened. I handle those with explicit unsubscribe on teardown, isolating failures per observer, and logging events."

"First I'd ask a few questions: how many levels, which vehicle types, do spot sizes matter, and is pricing hourly or flat. Assuming levels, three spot sizes and hourly fees, I'd have a ParkingLot that owns Levels, and each Level owns ParkingSpots. A spot knows its size and whether it's free. A Vehicle has a plate and a size; I'd use an enum for size rather than a subclass per vehicle, because the vehicle types don't behave differently here. When a car enters, the lot asks a SpotAllocator for a suitable free spot and creates a Ticket holding the vehicle, spot and entry time. On exit, a FeeCalculator turns the ticket into a charge. I'd keep allocation and pricing as interfaces so a nearest-spot rule or weekend rate can be swapped in. And I'd make claiming a spot safe when two entry gates try at once."

"The first thing I'd separate is the book from its copies. A Book is the title, author and ISBN; a BookCopy is one physical item on the shelf with its own barcode and status, available, on loan or lost. The library can own five copies of one book, and you borrow a copy, not a title. Then a Member with an id and a membership type, and a Loan that links one copy to one member with a borrow date, a due date and a return date. Loans deserve their own class because they have their own data and history. The rules, like how many books a member can hold or how long a loan lasts, I'd put in a LoanPolicy that a LibraryService checks before creating a loan. That keeps Book and Member simple and lets rules differ by membership type."

"At my last company we had a notification module where BaseNotification had grown into five levels of subclasses: EmailNotification, then ScheduledEmailNotification, then RetryingScheduledEmailNotification, and so on. Adding a retrying SMS meant copying half a branch, and a change in the base class broke three channels at once. I first wrote tests around the current behaviour for each channel. Then I pulled out the things that varied, the channel, the scheduling and the retry policy, into small objects behind interfaces, and made a single Notification class that holds one of each. I moved one channel at a time, keeping the old classes until the new path passed the same tests. At the end we had one class and a handful of small parts, and adding a new channel became a single class."

"Early in my career I built an internal reporting tool and was keen on patterns. For exporting reports I added an Exporter interface, an abstract base exporter, a factory, and a registry that loaded exporters by name from config. We only ever had one format, CSV. For a year, every small change meant reading four files to find the one line that mattered, and a new teammate asked me why it was so complicated. I couldn't give a good answer. I collapsed it into a single CsvExporter class, which cut the code by more than half and made the bug fixes trivial. When we did later add Excel, pulling out an interface took an afternoon. My rule now is to add the abstraction when the second real case arrives, not when I imagine it might."

"In my final-year project I built a small hospital appointment system. The main classes were Patient, Doctor, Appointment, and a Schedule that belonged to each doctor and held their free slots. An AppointmentService took a request, asked the doctor's schedule for a free slot, and created the Appointment. Notifications went through a separate Notifier class so the booking logic didn't know about email. What I'd change now: I put the cancellation rules, like no cancelling within two hours, directly inside the Appointment class with a bunch of if statements, and every new rule meant editing it. Today I'd pull those into a small CancellationPolicy object, so the rules could differ by department and be tested on their own without building whole appointments."

"I'd start by asking, not ruling. Maybe there's a second implementation on the roadmap I don't know about. If there is, and it's soon, the design might be right. If it's a just-in-case, I'd explain the cost in the review: three extra types and a factory that every reader has to click through, to reach one class that does the work. I'd suggest shipping the single concrete class and point out that extracting an interface later, when a real second case shows up, is a quick and safe refactor. I'd keep it about the code, not about their skills, and say what they got right, like keeping the class small and testable. If they still feel strongly and it's not harmful, I'd let it go rather than block the release over style."

"I'd explain the risk in concrete terms: every piece of code that holds the parent type assumes all its methods work. With this subclass, some of them will blow up at run time, and nothing at compile time will warn anyone. It's a sign the parent is promising too much. So I'd look for the smallest fix that still fits the deadline. Often that's splitting out a narrower interface with just the methods the new class really supports, and having the callers that need it depend on that instead. If that's too big for now, I'd suggest making it a separate class that doesn't inherit at all. If we truly must ship it this way, I'd want it documented, kept away from generic code paths, and a ticket to fix it right after the release."

"I wouldn't try to rewrite it, and I wouldn't just add another two hundred lines either. First I'd find the exact methods my feature touches and write characterization tests around them: tests that record what the code does today, even the odd parts, so I'll know if I change it by accident. Then I'd extract the logic I need into a new, focused class, and have the old methods delegate to it, so every caller still works unchanged. My feature goes into the new class, where it's small enough to test properly. If the class creates its own dependencies, I'd add a way to pass them in so the tests don't hit a real database. I'd keep each step a separate small commit, and I'd tell the team what I extracted so the next person can keep going the same way."