What is the difference between an abstract class and an interface in C ?

Understanding the distinction between abstract classes and interfaces is fundamental for any C# developer. Both are crucial object-oriented programming (OOP) constructs that facilitate abstraction and polymorphism, but they serve different purposes and offer distinct capabilities within the C# language. This guide will clarify their core differences, use cases, and how they contribute to robust software design.

Direct Summary: Abstract Class vs. Interface in C#

An abstract class in C# provides a common base with some implementation, allowing partial abstraction. It can contain concrete methods, fields, and constructors, and a class can inherit from only one abstract class. An interface defines a contract with no implementation prior to C# 8 (though C# 8 and later allow default implementations), enabling full abstraction. A class can implement multiple interfaces, fostering greater flexibility and supporting the “can-do” relationship.

Key Concepts & Related Terms

To fully grasp the differences, it’s helpful to be familiar with these related programming concepts:

• Abstract Classes: Classes that cannot be instantiated directly and often contain abstract members.
• Interfaces: Blueprints for classes that define a set of members that implementing classes must provide.
• Inheritance: A mechanism where one class acquires the properties and behaviors of another class (“is-a” relationship).
• Polymorphism: The ability of an object to take on many forms, often achieved through inheritance or interfaces.
• Design Principles: Guidelines for creating robust, maintainable, and scalable software (e.g., SOLID principles).

Detailed Comparison: Abstract Class vs. Interface

1. Implementation Capabilities

Abstract classes can have both fully implemented (concrete) methods and abstract methods (those without an implementation). This means an abstract class can provide some default behavior that derived classes can inherit directly, while also enforcing that certain methods *must* be implemented by those derived classes.

Interfaces, prior to C# 8, could only declare method signatures, acting purely as a blueprint without any implementation. With the introduction of C# 8, interfaces can now include default implementations for methods. While this blurs the lines slightly, the core distinction remains: interfaces primarily define a contract of behavior, whereas abstract classes can offer a mix of defined and undefined behaviors.

2. Inheritance vs. Implementation

In C#, a class can inherit from only one abstract class. This establishes a strong “is-a” relationship, meaning the derived class *is* a type of the base abstract class. For example, a Dog *is an* Animal.

Conversely, a class can implement multiple interfaces. This establishes a “can-do” relationship, meaning the implementing class *can perform* the actions defined by the interface. For example, a Bird *can* Fly (implements IFlyable), but it isn’t necessarily a type of IFlyable in the same way it’s a type of Animal.

3. Abstraction Level

Interfaces typically represent a higher level of abstraction, focusing solely on the “what” — the contract of methods a class must provide. They don’t dictate any implementation details (apart from C# 8 default implementations, which are still optional and primarily for backward compatibility or mix-ins).

Abstract classes, by having concrete methods and fields, provide a partial implementation. They define some of the “how” in addition to the “what,” offering a lower level of abstraction compared to pure interfaces.

4. Member Types

This is a crucial point demonstrating up-to-date knowledge. Before C# 8, interfaces were purely abstract. Now, they can have default implementations for methods, properties, and events. However, abstract classes still offer more flexibility in terms of member types; they can contain fields, constructors, static members, and more, which interfaces generally cannot (with some very specific exceptions like static abstract members in C# 11).

5. Use Cases

Use an abstract class when you have a set of related classes that share common functionality and a common base type, but where some behavior needs to be specialized by derived classes. For instance, an Account abstract class could define common methods like Deposit() and an abstract CalculateInterest() method that differs for SavingsAccount, CheckingAccount, and LoanAccount.

Use an interface when you want to define a contract for behavior that can be implemented by unrelated classes. For example, an IDrawable interface could be implemented by Circle, Square, and even DataChart, even though these classes may not share a common inheritance hierarchy.

Interview Hints & Practical Applications

1. Keywords: `abstract` and `virtual`

Be prepared to discuss the abstract keyword for classes and methods. Explain that an abstract method has no body and must be implemented (overridden) by non-abstract derived classes. An abstract class cannot be instantiated directly.

Example: “In a banking system project, we had different account types like SavingsAccount, CheckingAccount, and LoanAccount. Each needed a CalculateInterest() method, but the calculation logic differed. I used an abstract Account class with an abstract CalculateInterest() method. This enforced that every specific account type *had* to implement its own interest calculation logic, preventing errors and ensuring consistency across all account types.”

Also, discuss the virtual keyword in the context of abstract classes. A virtual method in an abstract class (or any class) has a default implementation but can be overridden by derived classes. This offers flexibility: derived classes *can* change the behavior, but aren’t forced to.

Example: “Building on the banking example, the Account class also had a Withdraw() method. I made this virtual. This allowed a default withdrawal behavior to be defined in the base Account class, but also allowed specific account types (like CheckingAccount) to override Withdraw() to handle overdraft fees, demonstrating the flexibility of virtual methods.”

2. Design Principles: Liskov Substitution Principle (LSP)

Mention the Liskov Substitution Principle and how both abstract classes and interfaces support it. LSP states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. Proper use of abstract classes and interfaces ensures that derived classes or implementing classes adhere to the contract defined by the base type.

Example: “The Liskov Substitution Principle was crucial in the banking project. We had a ProcessTransactions() function that accepted any Account object. Because each derived class (SavingsAccount, CheckingAccount, etc.) adhered to the contract defined by the abstract Account class (and any implemented interfaces), I could seamlessly substitute a SavingsAccount for a LoanAccount without altering the correctness of ProcessTransactions(). This ensured type safety and flexibility in our financial operations.”

3. Loose Coupling and Dependency Injection with Interfaces

Explain how interfaces are paramount for achieving loose coupling and facilitating dependency injection. Loose coupling means components are largely independent, reducing the impact of changes in one part of the system on others. Dependency injection is a technique where dependencies are provided to a class from the outside, rather than the class creating them itself, often using interfaces.

Example: “In a reporting module, we needed to generate reports in various formats (PDF, CSV, Excel). I defined an IReportGenerator interface. Different classes, such as PdfReportGenerator, CsvReportGenerator, and ExcelReportGenerator, implemented this interface for each format. Using dependency injection, I could easily switch between report generators without modifying the core reporting logic. This loose coupling made the code much more maintainable – adding a new format simply required implementing the interface – and highly testable, as I could easily mock the IReportGenerator for unit tests.”

4. Trade-offs

Briefly mention the trade-offs. While interfaces provide great flexibility, changes to an interface (especially adding new members without default implementations) can impact *all* implementing classes, requiring them to be updated. Changes to an abstract class are often more localized, primarily affecting only its direct derived classes, as the base class can provide default implementations or new concrete members without breaking existing derived classes.

Example: “While interfaces offer tremendous flexibility and promote extensibility, we were cautious about modifying the IReportGenerator interface in our reporting module. Any change to its core contract would require updates to *all* implementing classes. With abstract classes, like our Account class, changes are often more localized, impacting only derived classes that explicitly override or rely on specific members. We carefully weighed these trade-offs when deciding between interfaces and abstract classes, considering the potential impact of future changes on our codebase.”

C# Code Sample: Abstract Class and Interface

This code sample illustrates the core concepts discussed:

// Abstract Class Example
public abstract class Animal
{
    // Concrete method: has an implementation
    public void Sleep()
    {
        Console.WriteLine("Zzzzz...");
    }

    // Abstract method: declared but not implemented; must be overridden by derived classes
    public abstract void MakeSound();

    // Virtual method: has a default implementation but can be overridden by derived classes
    public virtual void Move()
    {
        Console.WriteLine("Moving slowly.");
    }
}

// Dog class inherits from Animal, must implement MakeSound()
public class Dog : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("Woof!");
    }

    // Override virtual method to provide specific behavior
    public override void Move()
    {
        Console.WriteLine("Running!");
    }
}

// Interface Example
public interface IFlyable
{
    // Method signature: declares a method that implementing classes must provide
    void Fly();

    // Default implementation (C# 8 and later): provides a default behavior
    // that implementing classes can use or override
    void Glide()
    {
        Console.WriteLine("Gliding through the air.");
    }
}

// Bird class inherits from Animal AND implements IFlyable
public class Bird : Animal, IFlyable
{
    public override void MakeSound()
    {
        Console.WriteLine("Chirp!");
    }

    // Implement interface method Fly()
    public void Fly()
    {
        Console.WriteLine("Flying high!");
    }
    // Bird can use the default Glide() implementation or override it
}

// Usage Examples
public class Program
{
    public static void Main(string[] args)
    {
        Console.WriteLine("--- Dog Actions ---");
        Animal myDog = new Dog();
        myDog.Sleep();      // Output: Zzzzz... (from Animal's concrete method)
        myDog.MakeSound();  // Output: Woof! (from Dog's overridden abstract method)
        myDog.Move();       // Output: Running! (from Dog's overridden virtual method)

        Console.WriteLine("\n--- Bird Actions ---");
        Bird myBird = new Bird();
        myBird.Sleep();     // Output: Zzzzz... (from Animal)
        myBird.MakeSound(); // Output: Chirp! (from Bird's overridden abstract method)
        myBird.Move();      // Output: Moving slowly. (Bird uses Animal's default virtual method)
        myBird.Fly();       // Output: Flying high! (from Bird's implemented interface method)
        myBird.Glide();     // Output: Gliding through the air. (from IFlyable's default implementation)

        Console.WriteLine("\n--- Polymorphic Usage ---");
        // An IFlyable reference can point to any object that implements IFlyable
        IFlyable flyingThing = new Bird();
        flyingThing.Fly();   // Output: Flying high!
        flyingThing.Glide(); // Output: Gliding through the air.
    }
}