OOP Interview Questions

A programming paradigm that organises code around objects — units that combine data (state) and behaviour (methods). Its four pillars are encapsulation, abstraction, inheritance and polymorphism.

A class is a blueprint that defines properties and methods. An object is a concrete instance created from that blueprint, with its own values for those properties.

Encapsulation hides internal state and controls access to it. Abstraction exposes what an object does while hiding how. Inheritance lets a class reuse and extend another class. Polymorphism lets different objects respond to the same call in their own way.

A special method that runs automatically when an object is created. It initialises the object into a valid state. In C# it has the class name; in JavaScript it is named constructor.

Procedural code is organised as functions that operate on separate data. OOP bundles data with the functions that change it, so each object protects its own state and the program is a set of collaborating objects.

Fields store an object’s data. Properties expose that data through get/set accessors where you can validate or compute values. Methods are the behaviour — what the object can do.

They control visibility: public (anyone), private (only the class), protected (the class and subclasses), internal (the same assembly in C#). Keep members as private as possible and widen only when needed.

A field or method that belongs to the class itself rather than to an instance, so there is one shared copy. Use it for utilities and shared constants; avoid static mutable state because it is hard to test and not thread-safe.

The current instance. It is used to read the object’s own members, to distinguish fields from parameters with the same name, and to pass the current object to another method.

Encapsulation is about hiding data and protecting it behind methods (how the object stores and guards its state). Abstraction is about hiding complexity behind a simple contract (what the object does). Private fields are encapsulation; an interface is abstraction.

Overloading: several methods in the same class share a name but have different parameter lists; resolved at compile time. Overriding: a subclass redefines a base-class method with the same signature; resolved at runtime.

1class Calc { public int Add(int a, int b) => a + b; public double Add(double a, double b) => a + b; } // overloading
2class Animal { public virtual string Speak() => "..."; }
3class Dog : Animal { public override string Speak() => "Woof"; }                                // overriding

Use an abstract class when closely related types share state or implementation and you want to provide a common base. Use an interface to define a capability that unrelated types can implement; a class can implement many interfaces but inherit only one class.

Build behaviour by combining objects (has-a) rather than extending classes (is-a). Composition is more flexible: you can swap components at runtime and avoid fragile, deep hierarchies.

Association is any “uses” relationship. Aggregation is a has-a where the part can exist independently (a Team has Players). Composition is a has-a where the part’s lifetime depends on the whole (an Order has OrderLines).

A subclass reuses and extends a base class (an is-a relationship). Deep or wide hierarchies create tight coupling: a change in the base class can break subclasses — the fragile base class problem.

A virtual method has a default implementation that subclasses may override. An abstract method has no body and must be overridden; it can only exist in an abstract class.

A class receives the objects it depends on (usually as interfaces through its constructor) instead of creating them with new. That makes dependencies visible, swappable and easy to fake in tests.

1public class OrderService(IEmailSender email)
2{
3    public void Place(Order order)
4    {
5        // ...save the order...
6        email.Send(order.CustomerEmail, "Thanks for your order!");
7    }
8}

A class should have one reason to change. An Invoice class that calculates totals, saves to the database and emails PDFs has three; split it into Invoice, InvoiceRepository and InvoiceMailer so each change touches one class.

Add new behaviour by adding new code, not by editing tested code. Instead of a growing switch on payment type, define an IPaymentMethod interface and add a new class per method.

Clients should not depend on methods they do not use. Split a fat IMachine (Print, Scan, Fax) into IPrinter, IScanner and IFax so a simple printer does not implement methods that throw NotSupportedException.

High-level policy should not depend on low-level details; both should depend on abstractions. OrderService depends on IOrderRepository, and SqlOrderRepository implements it, so storage can change without touching business logic.

Single Responsibility: one reason to change. Open/Closed: extend without modifying. Liskov Substitution: subtypes must be usable as their base type. Interface Segregation: small, focused interfaces. Dependency Inversion: depend on abstractions, not concretions.

Code written for Rectangle assumes width and height change independently. A Square that keeps them equal breaks that assumption, so substituting a Square for a Rectangle produces wrong results.

Singleton ensures a class has one instance with a global access point. Drawbacks: hidden global state, tight coupling and hard-to-test code. In modern apps prefer registering a single instance in a DI container (AddSingleton).

It defines a family of interchangeable algorithms behind a common interface, so the algorithm can be chosen at runtime — for example, different shipping-cost or discount strategies — instead of a growing if/else chain.

A factory hides the logic of choosing and creating objects behind one method or class (ShapeFactory.Create("circle")). It is useful when creation depends on configuration or input, or when construction is complex.

A subject keeps a list of observers and notifies them when its state changes, without knowing what they do. C# events, JavaScript addEventListener and RxJS observables all follow it.

A collection-like abstraction over data access (GetById, Add, Remove) that keeps SQL or ORM code out of business logic. It helps testing and swapping storage, but with EF Core a thin generic repository often adds little value.

Each box shows the class name, attributes and operations with visibility (+ public, - private, # protected). A hollow triangle arrow is inheritance, a dashed one is interface implementation, a filled diamond is composition and a hollow diamond is aggregation.