آموزش الگوی طراحی تزریق وابستگی

قبل از اینکه درباره تزریق وابستگی صحبت کنم بهتره موضوع وابستگی رو با ذکر یه مثال توضیح بدم. فرض کنید ما یک کلاس به اسم ContactPage داریم که برای صفحه تماس با ما استفاده می‌شود. این کلاس توی برنامه‌ای استفاده شده که کابران از طریق ایمیل میتوانند با پشتیبانی ارتباط برقرار کنند. کلاس EmailService هم کار فرستادن ایمیل رو انجام میده. کد زیر رو یه نگاه بندازید.

 

 

وقتی داخل یک کلاس از کلاس دیگر استفاده بشود بین آنها وابستگی ایجاد میشه بنابراین در این مثال کلاس ContactPage به کلاس EmailService وابستگی دارد. وابستگی ها انواع مختلقی دارند و بدترین نوعش که بهش میگن وابستگی سخت یا hard dependency زمانی ایجاد میشه که با استفاده از new نمونه سازی توی کلاس وابسته انجام بشه. الان تو مثال بالا وابستگی ایجاد شده سخت است. وابستگی های سخت وقتی تو برنامه‌ای وجود داشته باشه تغییرات احتمالی آینده رو مشکل میکنه و همین طور تست نوشتن هم سخت میشه.

استفاده از الگوی طراحی تزریق وابستگی

الگوی طراحی تزریق وابستگی میگه بیاید به جای اینکه نمونه سازی رو توی کلاس انجام بدید از بیرون وارد کنید. تو مثال بالا اگه بخوایم تزریق وابستگی رو اعمال کنیم مثل شکل زیر میشه

 

الان ما عملا الگوی تزریق وابستگی رو پیاده کردیم ولی برای اینکه کارمون حرفه‌ای تر بشه لازمه یه نکته دیگر رو هم بگم و اون اینه که وقتی دارید الگوی تزریق وابستگی رو استفاده میکنید باید حواستون به یک اصل مهم توی طراحی شی‌گرا باشه و اون اینه که همیشه استفاده از اینترفیس به استفاده از کلاس ارجحیت داره یا به عبارت دیگه program to interface, not implementation.

الان تو مثال بالا ما این اصل رو رعایت نکردیم و کلاس EmailService رو به ContactPage تزریق کردیم. اگر در آینده تصمیم بگیریم به جای ایمیل از SMS  و یا حتی تماس استفاده کنیم چی میشه؟ با توجه به طراحی الان، مجبوریم کلاس ContactPage رو تغییر بدیم که به جای سرویس ایمیل از یه سرویس دیگه استفاده کنه و این یعنی بالا رفتن هزینه تغییرات، در صورتی که اگر اصلی رو که بالا گفتم رعایت کرده بودیم دیگه لازم نبود با تغییر روش تماس، کلاس ContactPage نیازی به تغییر داشته باشه. خب حالا اگر بخواهیم به جای کلاس از اینترفیس استفاده کنیم و هزینه تغییرات احتمالی آینده رو کاهش بدهیم چطوری میشه؟ یه نگاهی به کدهای زیر بندازید.

 

همان طور که در کدهای بالا قابل مشاهده است به جای استفاده از کلاس، اینترفیس را به کلاس ContactPage تزریق کردیم. در این صورت، اگر روش تماس با پشتیبانی در برنامه تغییر کند دیگه لازم نیست کلاس ContactPage رو هم تغییر بدهیم و فقط کافی است که پیاده‌سازی مورد نظر رو به کلاس ContactPage تزریق کنیم مثل آنچه که در شکل زیر نشان داده شده

 

اگر میخواهید حرفه‌ای برنامه نویسی کنید باید همیشه حواستون باشه که وابستگی‌ها رو تزریق کنید. بیشتر هم ترجیح بر این است که وابستگی‌ها از طریق سازنده تزریق بشوند. حالا این وسط به مشکلی ایجاد میشه دوباره به کد کلاس Application نگاه کنید ببینید متوجه میشید مشکل کجاست؟ سریع ادامه مقاله رو نخونیداا 🙂

راهنمایی: الان کلاس ContactPage فقط یک وابستگی دارد که یا EmailService بهش تزریق میشه و یا SMSService و خود این کلاس‌ها هم وابسته به کلاس‌های دیگری نیستند و پارامتر ورودی هم نمیگیرند. ولی آیا توی یک پروژه واقعی هم اینطور خواهد بود؟

قطعا در یک پروژه واقعی وابستگی کلاس‌ها به همدیگه زیاد است و این مساله ایجاد یک نمونه از کلاس رو خیلی تو در تو میکنه و باعث میشود که کدها ناخوانا بشوند و کارمون سخت بشه. برای برطرف شدن این مشکل کتابخانه‌هایی وجود دارند که کار تزریق وابستگی رو راحت میکنند. بهترین کتابخانه‌ برای اندروید Dagger است که در مقاله بعدی دربارش صحبت میکنیم.

دوستان عزیز هر جا براتون سوال مطرح شد کامنت بزارید خوشحال میشم بتونم پاسخ بدم. شاد باشید 🙂

 

درباره نویسنده

پست های مرتبط

5 نظر

  1. وحید

    سلام
    رنگ فونتت خوب نیست
    من میخوام یه اپ بنویسم مثل واتس اپ که تماس صوتی و تصویری داشته باشه البته با کاربران خیلی کم مثلا نهایتا ۱۰ نفر همزمان تماس با هم داشته باشن
    بنظرتون از چه زبانی استفاده کنم ؟
    react native خوبه؟

    پاسخ
    1. فهیمه قاسمی
      فهیمه قاسمی

      سلام
      رنگ فونت متن هارو تغییر دادم، فرصت کنم انشالله رو ظاهر سایت کار میکنم. اینکه گفتید کاربران خیلی کم منظورتون رو متوجه نشدم اگه منظورتون اینکه که کلا تعداد کاربرای اپتون کمه مثلا یه پروژه دانشجویی هست در این صورت از react native استفاده کنید

      پاسخ

پاسخ

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

2 × 2 =