اگرچه در نگاه اول هر دو ابزار برای تعریف یک قرارداد (Contract) به کار می‌روند، اما فلسفه وجودی، نحوه تفکر معماری و کاربردهای عملی آن‌ها کاملاً متفاوت است. یکی از رایج‌ترین سوالات در مصاحبه‌های فنی و جلسات Design Review این است: «چرا و چه زمانی باید Interface را به Abstract Class ترجیح دهیم؟»

در این مقاله تخصصی، ابعاد مختلف این دو مفهوم، اصول SOLID مرتبط با آن‌ها، الگوهای معماری مدرن و دلایل مهندسیِ ترجیح اینترفیس‌ها را عمیقاً بررسی می‌کنیم.

تعاریف پایه و فلسفه وجودی

برای درک صحیح تمایز این دو مفهوم، باید از زاویه «روابط اشیاء» به آن‌ها نگاه کنیم:

کلاس انتزاعی (Abstract Class) – رابطه Is-A

کلاس انتزاعی نیمی قرارداد و نیمی پیاده‌سازی است. وقتی از کلاس انتزاعی استفاده می‌کنید، در حال تعریف هویت و ریشه یک موجودیت (Identity) هستید.

• نمایانگر رابطه Is-A (است) می‌باشد. مثلاً: Dog یک Animal است.

• می‌تواند دارای وضعیت (State / Fields)، سازنده (Constructor)، متدهای پیاده‌سازی‌شده (Concrete Methods) و متدهای انتزاعی (Abstract Methods) باشد.

• ارث‌بری از آن به معنی پذیرش هویت و رفتار پایه آن کلاس است.

اینترفیس (Interface) – رابطه Can-Do

اینترفیس ۱۰۰٪ قرارداد محض است (در شکل سنتی خود). وقتی یک کلاس اینترفیسی را پیاده‌سازی می‌کند، در واقع متعهد می‌شود که یک توانایی یا قابلیت (Capability) را ارائه دهد.

• نمایانگر رابطه Can-Do (می‌تواند انجام دهد) است. مثلاً: Car می‌تواند IDrivable باشد، یا Document می‌تواند IPrintable باشد.

• به صورت استاندارد فاقد هرگونه State (فیلدها) است و تنها امضای متدها، خواص (Properties) و رویدادها را مشخص می‌کند.

• هیچ فرضی در مورد هویت کلاسی که آن را پیاده‌سازی می‌کند ندارد.

مقایسه ساختاری Interface و Abstract Class

جدول زیر تفاوت‌های کلیدی این دو ساختار را از منظر ویژگی‌های زبان و معماری نشان می‌دهد:

چرا باید از Interfaceها استفاده کنیم؟ (دلایل کلیدی و مزایای معماری)

اکنون به سوال اصلی برمی‌گردیم. دلایل مهندسی زیادی وجود دارند که چرا در طراحی سیستم‌های بزرگ و چابک، تمرکز اصلی روی استفاده از اینترفیس‌هاست:

غلبه بر محدودیت تک-ارث‌بری (Single Inheritance Limit)

اکثر زبان‌های شیءگرا (مانند Java و C#) برای جلوگیری از مشکلاتی نظیر Diamond Problem (تداخل کدهای چند کلاس والد)، ارث‌بری چندگانه کلاس‌ها را ممنوع کرده‌اند.

اگر شما وابستگی کدهای خود را روی Abstract Class قرار دهید، تک‌سهم ارث‌بری آن کلاس را می‌سوزانید!

اما یک کلاس می‌تواند ده‌ها اینترفیس مختلف را پیاده‌سازی کند. به عنوان مثال، یک کلاس OrderService در سیستم می‌تواند همزمان قابلیت‌های زیر را داشته باشد:

public class OrderService : IOrderProcessor, ILoggable, IDisposable, ICloneable
{
    // پیاده‌سازی تمام قراردادها بدون محدودیت در سلسله‌مراتب کلاس
}

اگر IOrderProcessor به صورت کلاس انتزاعی بود، OrderService دیگر نمی‌توانست از کلاس پایه دیگری ارث‌بری کند.

تحقق اصل وارونگی وابستگی (Dependency Inversion Principle - DIP)

اصل پنجم از اصول SOLID بیان می‌کند:

«ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند؛ هر دو باید به انتزاع‌ها (Abstractions) وابسته باشند.»

اینترفیس‌ها ابزار شماره یک برای پیاده‌سازی Dependency Injection (DI) هستند. وقتی ماژول شما به یک Interface وابسته است، هیچ اطلاعی از نحوه کارکرد داخلی یا کلاس واقعی پیاده‌کننده ندارد. این امر سیستم را بسیار انعطاف‌پذیر می‌کند.

// وابستگی به اینترفیس - Loose Coupling
public class PaymentProcessor 
{
    private readonly IPaymentGateway _gateway;

    public PaymentProcessor(IPaymentGateway gateway)
    {
        _gateway = gateway;
    }

    public void Process(decimal amount)
    {
        _gateway.Pay(amount);
    }
}

در این حالت، می‌توان به راحتی در زمان اجرای برنامه (Runtime) سرویس StripeGateway را با PayPalGateway یا SamanBankGateway جابه‌جا کرد، بدون آنکه حتی یک خط از کد PaymentProcessor تغییر کند.

قابلیت تست‌پذیری فوق‌العاده (Testability & Mocking)

در تست‌نویسی مدرن (Unit Testing)، شما باید واحدهای کد را به صورت کاملاً ایزوله تست کنید. این کار نیازمند ساخت اشیاء شبیه‌سازی‌شده (Mock / Stub) است.

فریم‌ورک‌های Mocking (مانند Moq، NSubstitute یا Mockito) بر روی اینترفیس‌ها بسیار سریع‌تر و بدون عوارض جانبی عمل می‌کنند.

• اگر به یک Abstract Class وابسته باشید که در سازنده خود عملیات سنگین (مثل اتصال به دیتابیس) انجام می‌دهد، تست‌نویسی بسیار دشوار یا غیرممکن می‌شود.

• اینترفیس‌ها هیچ کد اجرایی یا وضعیت پایه‌ای ندارند، بنابراین ساخت Mock از روی آن‌ها با ۱۰۰٪ ایزولاسیون انجام می‌شود.

اصل تفکیک اینترفیس (Interface Segregation Principle - ISP)

اصل چهارم SOLID می‌گوید:

«هیچ کلاسی نباید مجبور به پیاده‌سازی متدهایی شود که به آن‌ها نیازی ندارد.»

با اینترفیس‌ها می‌توان قراردادهای بسیار کوچک، چابک و هدفمند (Role Interfaces) ساخت. اما کلاس‌های انتزاعی معمولاً به مرور زمان دچار پدیده Fat Interface یا Bloated Class می‌شوند؛ چرا که توسعه‌دهندگان تمایل دارند متدهای عمومی جدید را به کلاس پایه اضافه کنند که باعث آلوده شدن تمام فرزندان می‌شود.

// طراحی خوب: اینترفیس‌های کوچک و تفکیک‌شده
public interface IDataReader { string Read(); }
public interface IDataWriter { void Write(string data); }

// یک کلاس فقط خواندنی نیازی به متد Write ندارد
public class ReadOnlyStream : IDataReader 
{
    public string Read() => "Data";
}

ترجیح ترکیب بر ارث‌بری (Composition over Inheritance)

یکی از شعارهای اصلی معماری نرم‌افزار مدرن این است: "Favor Composition over Inheritance".

ارث‌بری شدید از کلاس‌ها (حتی Abstract Classها) منجر به پدیده‌ای به نام Fragile Base Class Problem می‌شود؛ تغییر در کلاس پایه ممکن است به‌طور ناخواسته رفتار ده‌ها کلاس فرزند را بشکند.

استفاده از اینترفیس‌ها شما را تشویق می‌کند به جای ارث‌بری عمیق ساختارها، اجزای مختلف را مانند قطعات لگو کنار هم ترکیب (Compose) کنید.

چه زمانی باید از Abstract Class استفاده کنیم؟

با وجود تمام مزایای اینترفیس‌ها، مهندس ارشد نباید کلاس‌های انتزاعی را کاملاً کنار بگذارد. کلاس انتزاعی زمانی انتخاب درست است که:

1. اشتراک‌گذاری کد (Code Reuse): چند کلاس الگوریتم یا کد کاملاً یکسانی دارند و نمی‌خواهید کد را تکرار کنید (DRY Principle).

2. مدیریت وضعیت مشترک (Shared State): کلاس‌های فرزند نیازمند فیلدها و وضعیت‌های یکسانی هستند (protected string _connectionString).

3. الگوی Template Method: زمانی که اسکلت و مراحل یک الگوریتم ثابت است، اما جزئیات برخی مراحل را به فرزندان واگذار می‌کنید.

سناریوی عملی: طراحی سیستم ارسال اعلان (Notification System)

برای درک بهتر، یک سیستم ارسال پیام را بررسی می‌کنیم. ابتدا اینترفیس اصلی را برای تعریف قرارداد پیام‌رسانی تعریف می‌کنیم:

// 1. قرارداد کلی برای تمام کانال‌های ارسال
public interface INotificationSender
{
    Task<bool> SendAsync(string recipient, string message);
}

اکنون اگر کدهای مشترکی بین ارسال‌کننده‌های مبتنی بر وب (مثل نیاز به Retry Logic یا Logging) داشته باشیم، می‌توانیم یک کلاس انتزاعی واسط بسازیم که اینترفیس را پیاده‌سازی می‌کند:

// 2. کلاس انتزاعی برای به اشتراک‌گذاری کدهای پایه و الگوی Template Method
public abstract class BaseWebNotificationSender : INotificationSender
{
    protected readonly ILogger _logger;

    protected BaseWebNotificationSender(ILogger logger)
    {
        _logger = logger;
    }

    // پیاده‌سازی متد اینترفیس
    public async Task<bool> SendAsync(string recipient, string message)
    {
        _logger.Log($"Initiating send to {recipient}");
        
        // فراخوانی متد انتزاعی که فرزندان باید پیاده‌سازی کنند
        bool result = await ExecuteSendAsync(recipient, message);
        
        _logger.Log($"Send result: {result}");
        return result;
    }

    // الگوی Template Method
    protected abstract Task<bool> ExecuteSendAsync(string recipient, string message);
}

و در نهایت کلاس‌های عملیاتی (Concrete Classes):

// 3. پیاده‌سازی واقعی SMS
public class SmsNotificationSender : BaseWebNotificationSender
{
    public SmsNotificationSender(ILogger logger) : base(logger) { }

    protected override Task<bool> ExecuteSendAsync(string recipient, string message)
    {
        // کدهای مربوط به ارسال پیامک از طریق Kavenegar / Twilio
        return Task.FromResult(true);
    }
}

تحلیل این معماری:

• سرویس‌های بالا دست (مثل OrderProcessor) فقط و فقط به INotificationSender (اینترفیس) وابسته هستند.

• توسعه‌دهنده از مزایای کلاس انتزاعی (BaseWebNotificationSender) برای جلوگیری از تکرار کد Logging استفاده کرده است.

• اگر فردا سرویسی اضافه شود که کدهای Logging متفاوتی دارد، نیازی به ارث‌بری از BaseWebNotificationSender ندارد؛ کافیست مستقیماً INotificationSender را پیاده‌سازی کند!

تحول اینترفیس‌ها در زبان‌های مدرن (Java 8+ و C# 8+)

در گذشته یکی از دلایل اصلی تمایل به کلاس انتزاعی، عدم امکان نوشتن کدهای پیاده‌سازی‌شده در اینترفیس بود. اما در زبان‌های جدید ویژگی Default Interface Methods اضافه شده است.

این ویژگی به اینترفیس‌ها اجازه می‌دهد متدهایی با پیاده‌سازی پیش‌فرض داشته باشند، بدون آنکه پیاده‌سازی کلاس‌های موجود بشکند:

public interface ILogger
{
    void Log(string message);

    // Default Method در اینترفیس
    void LogError(string message) 
    {
        Log($"[ERROR]: {message}");
    }
}

این قابلیت فاصله عملیاتی اینترفیس و کلاس انتزاعی را کمتر کرده و وزن ترازو را بیش از پیش به نفع اینترفیس‌ها سنگین‌تر کرده است.

به عنوان یک قاعده کلی در معماری نرم‌افزار:

«همواره وابستگی‌های سیستم خود را روی Interfaceها بنا کنید. اگر به بازاستفاده کد (Code Reuse) نیاز پیدا کردید، یک Abstract Class به عنوان لایه واسط بین Interface و کلاس‌های عملیاتی اضافه کنید.»