Classes, properties, and interfaces

A property looks like a field from the outside and is really a pair of methods underneath.

public class Account
{
    public string Owner { get; }              // read-only after construction
    public decimal Balance { get; private set; }

    public Account(string owner, decimal balance = 0)
    {
        Owner = owner;
        Balance = balance;
    }

    public void Deposit(decimal amount) => Balance += amount;
}

{ get; private set; } is an auto-property: the compiler generates the backing field for you. Balance can be read from anywhere but only changed from inside Account itself — encapsulation without writing a private field and a public getter by hand.

Try it

Interfaces

public interface INotifier
{
    string Send(string message);
}

public class EmailNotifier : INotifier
{
    public string Address { get; init; } = "";
    public string Send(string message) => $"mail to {Address}: {message}";
}

public class SmsNotifier : INotifier
{
    public string Number { get; init; } = "";
    public string Send(string message) => $"sms to {Number}: {message}";
}

A C# class can implement any number of interfaces but inherit from only one base class — the same single-inheritance-for-classes, unlimited-for-interfaces split most object-oriented languages share. An interface can declare a default method body too (since C# 8), but its main job is still the contract: what a type promises to do. It cannot declare instance fields, so per-object state lives in the classes that implement it.

Polymorphism through the interface

List<INotifier> targets = new()
{
    new EmailNotifier { Address = "ops@example.com" },
    new SmsNotifier { Number = "555-0100" },
};
List<string> sent = targets.Select(t => t.Send("deploy finished")).ToList();

The loop — or here, Select — never needs to know which concrete type each INotifier actually is. Which Send() runs is decided at runtime by the object's real type, which is exactly what makes adding a ChatNotifier : INotifier later free at every place that already only ever depended on INotifier.

Common mistakes

• Hiding a method with new when you meant override. Speak is virtual and Dog overrides it, so the Animal-typed variable still runs the dog's version. Name is not virtual; Dog merely hides it with new, so which body runs depends on the variable's type, not the object's. The compiler warns (CS0108) when you hide without writing new, and that warning usually marks a bug.
• Exposing a public setter "for convenience". Balance { get; set; } lets any caller write a balance no deposit ever produced. Keep the setter private and give the class methods that enforce its rules.
• Asking an object what it is instead of asking it to act. Code like if (v is Motorbike) fee = Math.Min(fee, 6) outside the class spreads one type's rule across every caller, and the next caller forgets it. The cap belongs inside Motorbike.Fee, where the interface call picks it up automatically.

What interviewers ask

• "Abstract class or interface: when do you pick which?" An abstract class can hold state and constructors but a class may inherit only one; an interface is a contract any number of unrelated types can implement. Pick the interface for a capability, the base class for shared implementation.