OOP Interview Questions

A class is a design that describes what something has (properties) and can do (methods). An object is one instance created from it with new. Student is a class; Aarav and Diya are objects with their own values.

A special method with the class's name and no return type that runs once when an object is created. It sets up the object, and by requiring parameters it ensures no object exists without the values it needs, such as a student's name.

Encapsulation (a class protects its data and rules), inheritance (a class reuses and extends another), polymorphism (one call behaves differently for different types), and abstraction (code depends on what something does, not how).

The change. Classes are reference types: assignment copies the reference, not the object, so both variables point to the same object. To get an independent copy, create a new object.

For classes, == compares references by default: it asks whether both variables point to the same object. Two separately created objects are different objects. Records, or overriding Equals, give value-based equality.

Create a class that inherits from Exception and passes the message to base(message), adding any extra data, such as an ErrorNumber. Callers can then catch your application's rule failures separately from system errors and react to them specifically.

The parallel arrays went out of step, probably after sorting one of them. Replace them with one class that holds the student and the mark together, such as ExamResult, and keep a single collection of those objects.

A class that knows and does too much, such as a SchoolManager with hundreds of methods for students, fees, and exams. It is hard to change and test. Split it by responsibility into smaller classes, each with its own data and the rules that use that data.

Put the domain model and business rules that every application needs (entities, rule exceptions, interfaces) in the core library, with no dependency on UI, databases, or web frameworks. Keep presentation and infrastructure code in the projects that need them, which reference the core, never the other way round.

Keeping an object's data private and offering only safe, public ways to change it, so the object enforces its own rules. A fee invoice's status can change only through RecordPayment.

public: any code. private: only the same class (the default for members). protected: the class and classes that inherit from it. internal: any code in the same project (assembly).

A field is a variable inside a class. A property looks like a field from outside but runs code when read or written, so it can validate, calculate, or restrict access. Public data should be exposed through properties, not public fields.

{ get; } can be set only in the constructor. { get; private set; } can be changed by the class's own methods at any time. { get; init; } can be set in the constructor or an object initializer, and is fixed afterwards.

A rule that must always be true for an object. For a fee invoice: the status always matches the payments. The constructor checks the starting state and every method keeps the rule, so no sequence of calls can break it.

Instead of asking an object for its data and applying rules outside it, tell the object what to do and let it apply its own rules, such as invoice.RecordPayment(amount). This keeps each rule in one place.

Find every code path that writes the status, such as an admin screen or a direct SQL update. Make the status private set, changed only by the payment method, and restrict direct updates in the database. Correct existing invoices through proper adjustments that leave an audit trail.

No. Decide per property who legitimately changes it. Ids are set by data access code, simple descriptive fields may be freely editable, but values tied to rules, such as status or balance, should change only through methods.

It is deliberate defense in depth: C# gives fast, clear feedback, and the database protects the data if any path skips the application. Keep the rules consistent with shared error numbers and tests, and decide which layer is authoritative for each rule.

A class (the derived class) building on another (the base class), getting all its members and adding its own. Student : Person gets the names and FullName from Person and adds an admission number. Use it for true "is a" relationships.

: base(...) calls the base class's constructor with the given arguments, before the derived constructor's own code runs. It is required when the base class has no parameterless constructor.

Not for classes: a class has exactly one base class (error CS1721 otherwise). A class can implement many interfaces, which covers most needs for multiple "kinds" of behavior.

private members are visible only inside the class itself, even derived classes cannot use them. protected members are visible to the class and every class that inherits from it, but not to outside code.

is with a pattern (if (p is Student s)) checks and converts safely. as returns null when the conversion fails. A cast (Student)p throws InvalidCastException when the object is not a Student. Prefer the is pattern.

Because InvalidMarkException inherits from SchoolRuleException, so it is one. A catch block matches the exception's type or any base type, which lets callers handle a whole family of errors at once or a specific one separately.

A role that changes over time was modeled as a subclass, but an object cannot change its type. Replace the deep tree with one Teacher class plus data that records the role per year, such as a ClassTeachers table, and keep hierarchies shallow.

Inherit for true, permanent "is a" relationships, such as a guardian being a person. Use composition, holding another object, for "has a", such as an invoice having payments. Composition is more flexible, so prefer it when in doubt.

No. The class design shares code; the table design suits storage and queries. They may differ as long as the mapping is clear: each derived class maps to its own table, including the inherited columns. ORMs support several mapping strategies for hierarchies.

One call behaving differently depending on the object's real type. Calling Describe() on a Person variable runs the student, teacher, or guardian version, depending on which object it holds.

virtual in the base class allows derived classes to replace a method or property. override in the derived class provides the replacement. base.Method() inside an override runs the base version too.

By default it returns the class name, such as SchoolApp.Core.Entities.Student. Overriding it gives a readable description, which interpolation, logging, and the debugger then use. Never put private data such as passwords in it.

Overloading: same name, different parameters, usually in one class, chosen at compile time. Overriding: same signature, new body in a derived class, needs virtual and override, chosen at run time from the object's real type.

override replaces the base method for every caller. new hides it: callers using a base-type variable still get the base version, and only derived-type variables see the new one. Hiding is almost always a mistake; the compiler warns with CS0114 when neither keyword is used.

A non-virtual method defines a fixed process and calls virtual (or abstract) steps that derived classes fill in. FeeNotice.Send always formats the same way, while Channel and Compose differ per channel.

Create a base class or interface for payment modes with the varying behavior as virtual or abstract members, and one class per mode. Choose the class in one place, then call it through the base type. A new mode becomes one new class, with no edits to existing logic.

When only a value differs, such as a rate or a limit: use a property set in the constructor instead. Use subclasses for different behavior, and interfaces when behavior must be swapped or combined at run time.

New behavior is added as new classes behind an existing base type or interface, so tested code is not edited. Only the place that chooses the implementation changes. This keeps changes small, reviewable, and low-risk, and lets teams work on different implementations independently.

A class marked abstract that cannot be created with new, only inherited from. It can hold shared code and abstract members without a body, which every derived class must override, such as ReportCard.FormatScore.

A contract listing members a class promises to provide, such as INotificationSender with Channel, CanReach, and Send. It has no constructors or instance fields; a class implements it with : IName and must provide every member.

Yes, any number, while having only one base class. A Teacher inherits from Person and is also an ISoftDeletable; a class could implement several capability interfaces at once.

An abstract class can hold fields, constructors, and shared code, and a class can have only one; it models "is a" for related classes. An interface is a contract a class can implement alongside others; it models "can do". Use an abstract class for shared code, an interface for a capability with possibly unrelated implementations.

Since C# 8, an interface member can have a body that implementing classes inherit, such as Describe() in INotificationSender. They are reachable only through the interface type, and they let you add members to an interface without breaking existing implementations.

Depending on what something does, not how it does it, and hiding the details. Notify knows only that a sender can reach a guardian and send a message; email servers and phone gateways stay hidden in the implementations.

Introduce an interface such as INotificationSender, wrap the current provider in one class that implements it, and change the forty call sites to use the interface. Then the new provider is one new class plus one line of setup, and both can be tested with fakes.

No. Add an interface when you need to swap implementations, fake a dependency in tests, or define a contract between teams or layers. An interface with one implementation and no such need only adds files and indirection.

Adding an abstract member to either breaks every implementation. Adding a normal or virtual method to an abstract class, or a default method to an interface, does not. Design contracts small and stable, version them deliberately, and prefer adding new interfaces over changing widely used ones.

A static member belongs to the class and has one shared copy, called on the class name, such as SchoolRules.GetGrade(92m). An instance member belongs to each object and is called on an object, such as diya.GetAgeOn(date).

A class that holds only static members and can never be instantiated (error CS0712). It suits pure helpers and rules with no stored state, such as SchoolRules or Math.

No other class may inherit from it; trying fails with error CS0509. Seal concrete classes that were not designed for extension, such as Student and Teacher.

const is fixed at compile time and allowed only for simple types such as numbers and strings; other projects copy the value when they compile. static readonly is set once at run time and works for any type, such as DateOnly, and callers always read the current value.

Splitting one class across several files that the compiler joins. The main use is generated code: a tool such as EF Core scaffolding writes one file, and your own code in another file survives regeneration.

When it has dependencies or behavior you may want to replace, such as sending messages or reading the database. Static code cannot be swapped through an interface or faked in tests. Keep static for pure, deterministic rules.

A static field is shared by every request in the app and resets when the app restarts; with several copies of the API, each has its own counter. Concurrent requests and restarts produce duplicates. Move the counter to the database, such as a SQL SEQUENCE, protected by a unique constraint.

Many teams seal concrete classes by default and unseal deliberately. Sealing documents that a class was not designed for inheritance, prevents fragile overrides, and allows small performance gains. Leave classes open only when extension is part of the design.

Never in static fields or memory of one instance. Durable shared state belongs in the database (sequences, rows with constraints) or a shared store such as a distributed cache; per-request state lives in objects created for that request. Static members hold only constants and pure logic.

A type with a fixed list of named values, such as InvoiceStatus { Unpaid, PartiallyPaid, Paid, Cancelled }. It replaces magic strings: invalid values and typos fail the build, and editors list the valid options.

A type, written in one line such as record MarkEntry(int EnrollmentId, int ExamSubjectId, decimal? MarksObtained), with init-only properties, value equality, a readable ToString(), and with expressions for copies with changes.

status.ToString() returns the member name, such as "PartiallyPaid". Enum.Parse<InvoiceStatus>("Paid") converts text back, and Enum.TryParse does it safely, returning false for unknown text.

A struct is a value type: assignment copies the whole value, it cannot be null (unless nullable), and it cannot inherit. A class is a reference type: assignment copies a reference to one shared object. Use structs for small immutable values, classes for entities.

0, whether or not a member has that value. If no member is 0, an unset enum field holds an undefined value, as with Gender. Make 0 a safe default, or require the value in the constructor, and use Enum.IsDefined for values from outside.

It creates a copy of a record (or struct) with some properties changed, leaving the original untouched: entered with { MarksObtained = 90m }. It is how you "change" immutable data.

Replace status strings with an enum whose member names match the database CHECK constraint exactly, and convert with ToString() and Enum.Parse. Typos then fail the build, and a test can check that every enum name is allowed by the constraint.

Usually not. Entities have identity: two students with identical names and birth dates are still different people, distinguished by Id, and they change over time. Records compare by value and are meant to stay fixed, which suits DTOs, messages, and value objects.

Classes for entities with identity and behavior; records for data passed between layers and compared by value; readonly record structs for tiny, frequently created values; enums for fixed option lists. Document the convention so the whole team chooses the same way.

A class that represents one row of a database table, with one property per column, such as Mark for the Marks table. Data access code reads rows into entities and saves entities back as rows.

Introduced in C# 11, it forces the property to be set in the object initializer when the object is created; otherwise the build fails with CS9035. It suits entities without constructors, such as Subject.Name.

Add ? to the type: decimal? for MarksObtained, string? for Remarks, DateOnly? for a return date. NOT NULL columns use the plain type, so the class tells callers exactly what may be missing.

The foreign key property, such as StudentId, holds the stored Id and is always present. The navigation property, such as Student, holds the linked object and is filled only if the code loaded it, so it is nullable.

Put them in an abstract base class, such as AuditableEntity with CreatedAt, CreatedBy, UpdatedAt, and UpdatedBy, and a SoftDeletableEntity for soft-delete columns. Entities inherit what their table has.

As a class with the two foreign keys, which together form the key, plus any data about the link, such as Relationship and IsPrimaryContact, and optional navigation properties to both sides. There is no separate Id.

The entity property type: it is probably int, which drops the fraction. Change it to decimal, fix affected data, and add an automated test that compares every entity's property types and nullability with the database columns, so a mismatch fails the build.

A mix. Put rules inside entities where breaking them is expensive, such as payments and identity, so invalid objects cannot exist. Keep simple lookup tables plain, with rules in services. Fully anemic models scatter rules; fully rich models can fight data access tools.

For a database-first system with many tables, generate (scaffold) them so they always match the schema, and keep custom code in partial classes. Hand-write them when the domain model must differ from the tables. Either way, verify them automatically against the schema.

A data transfer object: a simple class or record that carries exactly the data one API call or screen needs, such as StudentDto. It has no business rules and no database-only fields.

Entities mirror the database and expose everything: password hashes, audit columns, soft-delete flags, and any column added later. DTOs send only what the client needs, so internal data cannot leak and database changes do not break clients.

A static method in a static class whose first parameter has this, such as ToDto(this Student student). It can be called like an instance method, student.ToDto(), without changing the original class. Its namespace must be imported with using.

Each direction needs different fields: a response has an Id and readable values; a create request has no Id; an update request contains only fields that may change. One shared DTO would accept or expose fields it should not.

A client adds extra fields to a request, such as a status or role, and the server saves them because it bound the request to an entity. Request DTOs contain only the allowed fields, so anything else in the JSON is ignored.

Building one simple DTO from values spread across linked entities, such as an invoice summary that includes the student's name from Enrollment.Student. Clients get a small, ready-to-show shape without knowing how tables are joined.

Introduce a DTO with only the needed fields and map the entity to it before returning. Check all other endpoints for returned entities, add a review rule or analyzer that forbids entities in controller responses, and consider rotating credentials if hashes were exposed.

Hand-written mapping is explicit, compiler-checked, and easy to debug; renamed properties break the build. Libraries reduce repetitive code for many similar mappings but can silently skip properties. Choose per project size, and test mappings either way.

The DTO is the public contract; the database and entities can change behind it while mapping adapts. Breaking changes to the DTO are made deliberately, with versioning, so apps already on phones keep working.