اصل وارون سازی وابستگی

اصل وارون سازی وابستگی - Dependency Inversion principle یا (DIP)

مقایسه با دنیای واقعی:

باز هم در مورد کامپیوتر روی میز کارتان می خواهیم صحبت کنیم. اجزای مختلف مانند حافظه RAM، هارد (hard disk)، سی دی رام (CD-ROM) و غیره به صورت ضعیف به مادر بورد متصل شده اند.

نتیجه اینکه اگر در ادامه یک قسمت از کار افتاد راحت می توان آن را با یک قطعه جدید جایگزین کرد.

حالتی را تصور کنید که تمام اجزا به صورت پیوند قوی با یکدیگر متصل شده باشند، یعنی هیچ قسمتی را نمی توان از روی مادر بورد جدا کرد. حال اگر RAM از کار افتاد باید یک مادر بورد جدید خریداری کنید که در این صورت خیلی گران تمام می شود.

شناسایی مشکل در برنامه نویسی

لطفا به کد زیر نگاه کنید.

public class CustomerBAL
{
    public void Insert(Customer c)
    {
        try
        {
           //Insert logic
        }
        catch (Exception e)
        {
            FileLogger f = new FileLogger();
            f.LogError(e);
        }
    }
}

public class FileLogger
{
    public void LogError(Exception e)
    {
       //Log Error in a physical file
    }
}

در کد بالا CustomerBAL مستقیم به کلاس FileLogger وابسته است که استثناهای فایل فیزیکی را log می کند. حال فرض کنید فردا مدیریت تصمیم می گیرد که استثنا ها را در Event Viewer شروع به log کند. جه اتفاقی می افتد؟ یک خطای جدید ممکن است ایجاد شود.

DIP چیست؟

DIP می گوید: "ماژول های سطح بالا نبایستی به ماژول های سطح پایین وابسته باشند. بلکه هر دو باید به یک انتزاع وابسته باشند."

راه حل با DIP

public interface ILogger
{
    void LogError(Exception e);
}

public class FileLogger:ILogger
{
    public void LogError(Exception e)
    {
       //Log Error in a physical file
    }
}
public class EventViewerLogger : ILogger
{
    public void LogError(Exception e)
    {
       //Log Error in a physical file
    }
}
public class CustomerBAL
{
    private ILogger _objLogger;
    public CustomerBAL(ILogger objLogger)
    {
        _objLogger = objLogger;
    }

    public void Insert(Customer c)
    {
        try
        {
           //Insert logic
        }
        catch (Exception e)
        {            
            _objLogger.LogError(e);
        }
    }
}

همانگونه که می بینیید کلاینت به یک abstraction (انتزاع) با عنوان ILogger وابسته است. که خود می تواند به عنوان یک نمونه برای سایر کلاس ها استفاده شود.

بنابراین هر پنج اصل SOLID را بحث کردیم. از عمو باب تشکر می کنیم.

آیا این پایان راه است؟

سوال دیگری هست و آن اینکه آیا اصول دیگری به جز مواردی که عمو باب ارائه و طبقه بندی کرده است وجود دارد؟ پاسخ مثبت است، اما قصد نداریم که ریز تک تک این اصول را بیان کنیم. و به صورت فهرست وار این اصول عبارتند از:

• Program to Interface Not Implementation.
• Don't Repeat Yourself.
• Encapsulate What Varies.
• Depend on Abstractions, Not Concrete classes.
• Least Knowledge Principle.
• Favor Composition over Inheritance.
• Hollywood Principle.
• Apply Design Pattern wherever possible.
• Strive for Loosely Coupled System.
• Keep it Simple and Sweet / Stupid.

نتیجه گیری

نمی توانیم از تغییر پرهیز کنیم. تنها کاری که می توانیم انجام دهیم، توسعه و طراحی نرم افزاری است که قادر به مدیریت این تغییرات باشد.

با امید اینکه از این مقاله لذت برده باشید.

منبع: Object Oriented Design Principles