در قسمت های قبلی از این آموزش از وب سایت پرووید ما در رابطه با پیاده سازی اصل Inversion of Control با استفاده از الگوی طراحی Factory صحبت کردیم. این موضوع اولین قدم ما در رسیدن به یک طراحی Loosely Coupled بود. در ادامه این آموزش ما در رابطه با پیاده سازی اصل Dependency Inversion به عنوان دومین قدم در روند رسیدن به یک طراحی Loosely Coupled صحبت خواهیم کرد.
در ابتدا باید با هم اصل Dependency Inversion (معکوس سازی وابستگی) را بررسی کنیم. این اصل یکی از اصول پنجگانه SOLID است که در طراحی شی گرا اولین بار توسط آقای Robert C. Martin مطرح شد.
تعریف اصل Dependency Inversion
بند اول: ماژول های سطح بالا (High Level Module) نباید به ماژول های سطح پایین (Low Level Module) وابسته باشند. بلکه هر دوی آنها باید به Abstraction وابسته باشند.
بند دوم: Abstraction ها نباید وابسته به Details (جزئیات) باشند. Details (جزئیات) باید وابسته به Abstraction باشند. بیایید برای بهتر فهمیدن اصل Dependency Inversion مثالی که از قسمت های قبلی بررسی کرده بودیم را یک بار دیگر در نظر بگیریم. لطفاً کد زیر را با دقت نگاه کنید.
public class CustomerBusinessLogic
{
public CustomerBusinessLogic()
{
}
public string GetCustomerName(int id)
{
DataAccess _dataAccess = DataAccessFactory.GetDataAccessObj();
return _dataAccess.GetCustomerName(id);
}
}
public class DataAccessFactory
{
public static DataAccess GetDataAccessObj()
{
return new DataAccess();
}
}
public class DataAccess
{
public DataAccess()
{
}
public string GetCustomerName(int id) {
return "Dummy Customer Name"; // get it from DB in real app
}
}
در مثال بالا ما الگوی طراحی Factory را برای رسیدن به Inversion of Control استفاده کردیم. اما موضوع اینجاست که کلاس CustomerBusinessLogic از یک کلاس Concrete (امیدوارم تفاوت بین کلاس های Concrete و Abstract را بدانید.) استفاده می کند و آن DataAccess است. بنابراین بین دو کلاس DataAccess و CustomerBusinessLogic هنوز هم Tight Coupling وجود دارد. هر چند که ما مسئولیت ساختن یک شی جدید از این وابستگی را به کلاس Factory محول کردیم. بیایید در ادامه با پیاده‌سازی اصل Dependency Inversion بر روی دو کلاس DataAccess و CustomerBusinessLogic آن ها را بیش از پیش Loosely Coupled کنیم.
در بند اول از تعریف اصل Dependency Inversion گفتیم که ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند. بلکه هر دوی آنها باید به Abstraction وابسته باشند. در اینجا بیایید تصمیم بگیریم که کدام کلاس ماژول سطح بالا و کدام کلاس ماژول سطح پایین است. ممکن است حدس زده باشید که ماژول سطح بالا کلاس یا ماژولی است که به بقیه ی کلاس ها یا ماژول ها وابستگی دارد. بنابراین در مثال ما CustomerBusinessLogic که به کلاس DataAccess وابسته است ماژول سطح بالا و DataAccess ماژول سطح پایین است. بنابراین اگر بخواهیم بند اول از اصل Dependency Inversion را پیاده سازی کنیم نباید کلاس CustomerBusinessLogic به کلاس DataAccess وابسته باشد. هر دوی آنها باید به Abstraction وابسته باشند. بند دوم در تعریف اصل Dependency Inversion می گفت که Abstraction ها نباید وابسته به جزئیات باشند. بلکه جزئیات باید وابسته به Abstraction باشند.
پرووید: مرکز آموزش تخصصی برنامه نویسی و توسعه نرم افزار