اصل Dependency Inversion یا معکوس سازی وابستگی در SOLID چیست؟



visibility  
mode_comment   ۰

حتما در طول یادگیری برنامه نویسی، عبارت کد تمیز را بارها و بارها شنیده اید. کد تمیز ویژگی اسرار آمیزی است که باعث می شود کدهای شما خوانا و تغییر پذیر شوند. با کد تمیز شما تبدیل به شوالیه ای می شوید که همیشه آماده جنگ با اژدها است! مارتین فاولر (Martin Fowler)، شوالیه مشهور علم کد تمیز در اینباره می گوید:

هر احمقی می تواند کدی بنویسد که یک کامپیوتر آن را بفهمد. برنامه نویس های خوب کدهایی می نویسند که انسان ها می توانند آن را بفهمند.

اما آیا تا به حال فکر کرده اید چه چیزی باعث می شود یک کد تمیز باشد یا نباشد؟ پیدا کردن کد کثیف با دنبال کردن بوی بد کد (Code Smell) ممکن می شود. در برنامه نویسی به علائمی که نشان می دهند یک کد تمیز نیست اصطلاحا بوی بد می گوییم. این علائم عبارت اند از:

  • سفتی یا Rigidity: ایجاد تغییر در کدها مشکل است
  • شکنندگی یا Fragility: طراحی کد برنامه به راحتی در هم می شکند و به هم می ریزد
  • بی تحرکی یا Immobility: به سختی می توان کدها را دوباره استفاده کرد. اصطلاحا Usability کد پایین است
  • چسبندگی یا Viscosity: انجام کار درست در کدها مشکل است!

به محض استشمام این بوهای بد در کدهای خودتان، باید به فکر یادگیری طراحی کد تمیز بیفتید. برای طراحی کد تمیز باید از یک سری اصول یا فوت کوزه گری پیروی کنید! یکی از این اصول SOLID است. SOLID بر پنج اصل استوار است:

  1. Single Responsibility Principle یا اصل تک وظیفگی (SRP)
  2. Open/Closed Principle یا اصل باز و بسته بودن (OCP)
  3. Liskov Substitution Principle یا اصل جانشینی لیسکف (LSP)
  4. Interface Segregation Principle یا اصل تفکیک Interface (ISP)
  5. Dependency Inversion Principle یا اصل وارونه کردن وابستگی (DIP)

در این مطلب به معرفی اصل آخر SOLID یعنی اصل وارونگی وابستگی می پردازیم.

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

اصل وارونگی وابستگی یا Dependency Inversion Principle تاکید می کند که ماژول های سطح بالای برنامه نباید به ماژول های سطح پایین آن وابسته باشند. رابرت مارتین (Robert Martin) مشهور به عمو باب در این رابطه می گوید:

الف: ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند. هر دوی آن ها (ماژول های سطح بالا و پایین) نباید به Abstraction ها وابسته باشند.

ب: Abstraction ها نباید به جزئیات وابسته باشند. جزئیات باید به Abstraction ها وابسته باشند.

خوب باید بگوییم که توضیح این اصل کمی مشکل است و گویا عمو هم در این رابطه خیلی موفق عمل نکرده! به زبان خیلی خیلی (و باز هم خیلی) ساده، ما باید همیشه از Interface ها و Abstract ها در برنامه نویسی استفاده کنیم.

Dependency Inversion چیست

یک پریز برق را در نظر بگیرید. تمام جزئیات سیم کشی برق در پشت پریز تعریف شده است. مثل اتصالات، سیم های در هم پیچیده و.... تمام این ها ماژول های سطح پایین سیستم برق هستند. سوکت های برق دستگاه های مختلف الکترونیکی را هم ماژول های سطح بالا در نظر می گیریم. با این تعریف در صورت نبود پریز، برای دریافت برق از سیم کشی ساختمان مجبور بودیم خودمان به طریقی سیم های دستگاه ها را به سیم های سیم کشی برق متصل نگه داریم! بنابراین ماژول های سطح بالا (سیم دستگاه های الکترونیکی) به ماژول های سطح پایین (سیم کشی ساختمان) وابسته بودند.

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

مثالی از اصل وارونه کردن وابستگی

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

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

Dependency Inversion چیست

با در نظر گرفتن درایور پایگاه داده ای که استفاده می کردید (مثل MySQL، SQLServer، Oracle و...) به عنوان ماژول سطح پایین، ماژول های سطح بالای شما یعنی کدهای برنامه به شدت به ماژول های سطح پایین وابسته بود. فقط در ذهنتان تصور کنید چه می شد اگر می خواستید از MySQL به یک پایگاه داده NOSQL مثل MongoDB مهاجرت کنید؟ فاجعه! شما باید تمام کوئری های وابسته را از جای جای برنامه پیدا می کردید و آن ها را یکی یکی تغییر می دادید.

روش درست این است که یک Interface برای پایگاه داده در نظر بگیریم. تمام درایورهای مختلف برای استفاده شدن موظف می شوند این Interface را پیاده سازی یا Implement کنند. از آن پس کدهای برنامه فقط به آن رابط ها متصل می شوند. به این ترتیب این وابستگی را وارونه کرده ایم!

نتیجه گیری

با اهمیت کدهای تمیز و یاد گرفتن روش رسیدن به آن آشنا شدید. به نشانه های یک کد کثیف بوی بد کد می گوییم. این بوهای بد عبارت اند از: سفتی، شکنندگی، بی تحرکی و چسبندگی که هرکدام معنی خاص خود را دارند. یکی از موارد لازم برای رسیدن به کد تمیز، رعایت اصول SOLID در کدنویسی است. در این مطلب با اصل آخر از اصول SOLID یعنی اصل وارونه کردن وابستگی یا DIP آشنا شدید. به غیر از مثالی که گفتیم، شما چه نمونه هایی از استفاده اصل آخر در کدنویسی به خاطر دارید؟ از خواندن نظرات شما همیشه خوشحال می شویم!

7Learn Experts
comment دیدگاه کاربران

add_circle ارسال دیدگاه

خوشحال میشیم دیدگاه و یا تجربیات خودتون رو با ما در میون بذارید :