در دنیای پر سرعت توسعه نرم افزار، پذیرش روش های کارآمد امری ضروری است. یکی از این روش ها که به رسمیت شناخته شده است، تزریق وابستگی (DI) است. این مقاله به جنبه‌های اصلی DI می‌پردازد، تعریف، اهمیت و سناریوهایی را که اجرای آن می‌تواند تحول‌بخش باشد، بررسی می‌کند. در مهندسی نرم افزار، تزریق وابستگی تکنیکی است که در آن یک شی (یا متد استاتیک) وابستگی های یک شی دیگر را تامین می کند. وابستگی شیئی است که می توان از آن استفاده کرد (یک سرویس). این تعریفی است که در همه جا از آن را خواهید دید، اما هنوز درک آن به خصوص آسان نیست. پس بیایید آن را بهتر درک کنیم.
قبل از اینکه بدانیم در برنامه نویسی به چه معناست، ابتدا ببینیم به طور کلی به چه معناست زیرا به ما کمک می کند تا مفهوم را بهتر درک کنیم.
وابستگی به معنای تکیه بر چیزی برای حمایت است. مثلاً اگر بگویم بیش از حد به تلفن‌های همراه متکی هستیم، این بدان معناست که ما به آنها وابسته هستیم. بنابراین قبل از رسیدن به تزریق وابستگی، ابتدا بیایید بفهمیم که وابستگی در برنامه نویسی به چه معناست. وقتی کلاس A از برخی متد های کلاس B استفاده می کند، گفته می شود که کلاس A دارای وابستگی کلاس B است.
در جاوا، قبل از اینکه بتوانیم از متدهای کلاس های دیگر استفاده کنیم، ابتدا باید شیء آن کلاس را ایجاد کنیم (یعنی کلاس A باید نمونه ای از کلاس B ایجاد کند).
بنابراین، به انتقال وظیفه ایجاد شی به شخص دیگری و استفاده مستقیم از وابستگی، تزریق وابستگی گفته می شود.
چرا باید از تزریق وابستگی استفاده کنم؟
فرض کنید یک کلاس خودرو داریم که شامل اشیاء مختلفی مانند چرخ، موتور و غیره است. در اینجا کلاس ماشین مسئول ایجاد تمام آبجکت های وابستگی است. حال، اگر در آینده تصمیم بگیریم MRFWheels را کنار بگذاریم و بخواهیم از چرخ های یوکوهاما استفاده کنیم، چه؟
ما باید شی ماشین را با وابستگی جدید یوکوهاما بازسازی کنیم. اما هنگام استفاده از تزریق وابستگی (DI)، می‌توانیم Wheels را در زمان اجرا تغییر دهیم (زیرا وابستگی‌ها را می‌توان در زمان اجرا تزریق کرد تا در زمان کامپایل این کار را انجام داد.).
شما می توانید DI را به عنوان واسطه ای در کد ما در نظر بگیرید که تمام کار ایجاد شی چرخ های ترجیحی و ارائه آن به کلاس Car را انجام می دهد.
کلاس ماشین ما را از ایجاد اشیاء چرخ، باتری و غیره مستقل می کند.
اساساً سه نوع تزریق وابستگی وجود دارد:
تزریق سازنده: وابستگی ها از طریق سازنده کلاس ارائه می شوند.
تزریق تنظیم کننده: کلاینت یک متد تنظیم کننده را نشان می دهد که انژکتور برای تزریق وابستگی استفاده می کند.
تزریق رابط: وابستگی یک متد تزریقی را ارائه می دهد که وابستگی را به هر کلاینت منتقل شده به آن تزریق می کند. کلاینت‌ها باید رابطی را پیاده‌سازی کنند که متد تنظیم‌کننده‌ای را که وابستگی را می‌پذیرد، نشان دهد.
بنابراین اکنون مسئولیت تزریق وابستگی به موارد زیر است:
اشیاء را ایجاد کنید
بدانید کدام کلاس ها به آن اشیا نیاز دارند
و همه آن اشیاء را برای آنها فراهم کنید
اگر تغییری در اشیاء وجود داشته باشد، DI آن را بررسی می کند و نباید به کلاسی که از آن اشیا استفاده می کند مربوط شود. به این ترتیب اگر اشیاء در آینده تغییر کنند، مسئولیت DI آن برای ارائه اشیاء مناسب به کلاس است.
وارونگی کنترل : مفهوم پشت DI
این بیان می کند که یک کلاس نباید وابستگی های خود را به صورت ایستا پیکربندی کند، بلکه باید توسط کلاس دیگری از خارج پیکربندی شود.
این پنجمین اصل S.O.L.I.D است، پنج اصل اساسی برنامه نویسی و طراحی شی گرا که بیان می کند که یک کلاس باید به انتزاع بستگی داشته باشد نه بر ادغام (به عبارت ساده، کدگذاری شده باشد).
طبق اصول، یک کلاس باید بر انجام مسئولیت های خود تمرکز کند نه بر ایجاد اشیایی که برای انجام آن مسئولیت ها نیاز دارد. و اینجاست که تزریق وابستگی وارد عمل می شود: اشیاء مورد نیاز را در اختیار کلاس قرار می دهد.
مزایای استفاده از DI
مزایای تزریق وابستگی به صورت خلاصه شامل زیر می باشد:
در تست واحد کمک می کند.
کد صفحه بویلر کاهش می یابد، زیرا مقدار دهی اولیه وابستگی ها توسط جزء انژکتور انجام می شود.
گسترش برنامه آسان تر می شود.
به فعال کردن اتصال شل، که در برنامه نویسی برنامه مهم است، کمک می کند.
تزریق وابستگی می تواند در موارد زیر مفید باشد:
تزریق وابستگی، ماژول‌های کد مختلف را از کار نمونه‌سازی ارجاعات به منابع رها می‌کند و وابستگی‌ها، حتی وابستگی‌های ساختگی، را قادر می‌سازد تا به راحتی جابجا شوند. با فعال کردن چارچوب برای ایجاد منبع، داده‌های پیکربندی متمرکز می‌شوند و به‌روزرسانی‌ها فقط در یک مکان انجام می‌شوند.
منابع تزریق شده را می توان از طریق فایل های Extensible Markup Language خارج از کد منبع سفارشی کرد. این امکان اعمال تغییرات را بدون نیاز به کامپایل مجدد کل پایگاه کد فراهم می کند.
برنامه ها بیشتر قابل آزمایش، نگهداری و استفاده مجدد هستند. این امکان پذیر است زیرا لاجیک کلاینت از نحوه پیاده سازی وابستگی های آن حذف شده است.
توسعه دهندگان را قادر می سازد تا روی موارد بیشتری کار کنند. توسعه دهندگان می توانند به طور مستقل کلاس هایی ایجاد کنند که همچنان از یکدیگر استفاده می کنند. آنها فقط باید رابط کلاس ها را بدانند.
تزریق وابستگی به طور مستقیم به تست واحد نیز کمک می کند. این می تواند جزئیات پیکربندی را به فایل های پیکربندی خارجی تبدیل کند. این سیستم را قادر می سازد بدون کامپایل مجدد پیکربندی شود.
معایب DI
یادگیری آن کمی پیچیده است و در صورت استفاده بیش از حد می تواند منجر به مشکلات مدیریتی و سایر مشکلات شود.
بسیاری از خطاهای زمان کامپایل به زمان اجرا منتقل می شوند.
چارچوب‌های تزریق وابستگی با بازتاب یا برنامه‌نویسی پویا پیاده‌سازی می‌شوند. این می تواند مانع استفاده از اتوماسیون IDE، مانند "یافتن مراجع"، "نمایش سلسله مراتب call ها" و بازسازی ایمن شود.
شما می توانید تزریق وابستگی را به تنهایی (Pure Vanilla) پیاده سازی کنید یا از کتابخانه ها یا فریم ورک های شخص ثالث استفاده کنید.
4 نقش در تزریق وابستگی
اگر می خواهید از این تکنیک استفاده کنید، به کلاس هایی نیاز دارید که چهار نقش اساسی را انجام دهند. اینها هستند:
سرویسی که می خواهید استفاده کنید.
کلاینتی که از خدمات استفاده می کند.
رابطی که توسط کلاینت استفاده می شود و توسط سرویس پیاده سازی می شود.
injector که یک نمونه سرویس ایجاد می کند و آن را به کلاینت تزریق می کند.
شما قبلاً سه نقش از این چهار نقش را با پیروی از اصل وارونگی وابستگی پیاده‌سازی می‌کنید. سرویس و کلاینت دو کلاسی هستند که اصل وابستگی قصد دارد با معرفی یک رابط، وابستگی را حذف کند.
می توانید نقش رابط را نادیده بگیرید و شیء سرویس را مستقیماً به کالاینت تزریق کنید. اما با انجام این کار، اصل وارونگی وابستگی را زیر پا می گذارید و کلاینت شما وابستگی آشکاری به کلاس سرویس دارد. در برخی شرایط، این ممکن است خوب باشد. اما اغلب، بهتر است یک رابط برای حذف وابستگی بین کلاینت و اجرای سرویس معرفی شود.
injector تنها نقشی است که توسط اصل وارونگی وابستگی لازم نیست. اما این یک مشکل نیست زیرا شما نیازی به اجرای آن ندارید.
تزریق وابستگی برای برنامه هایی که از اصل وارونگی وابستگی پیروی می کنند، مناسب است. شما در حال حاضر بیشتر نقشهای مورد نیاز را پیاده‌سازی کرده‌اید، و تکنیک تزریق وابستگی به شما امکان می‌دهد تا آخرین وابستگی به اجرای سرویس را حذف کنید.
تزریق وابستگی برای چه مواردی استفاده می شود؟
تزریق وابستگی برای مستقل ساختن یک کلاس از وابستگی های آن یا ایجاد یک برنامه با جفت آزاد استفاده می شود. تزریق وابستگی برای بهبود قابلیت استفاده مجدد کد مفید است. به همین ترتیب، با جدا کردن استفاده از یک شی، می‌توان وابستگی‌های بیشتری را بدون نیاز به تغییر کلاس جایگزین کرد.
تزریق وابستگی همچنین به پیروی از اصول طراحی شی گرا کمک می کند. پنج جنبه از OOP وجود دارد که هر حرف نماینده یک اصل است:
مسئولیت واحد.
باز/بسته
تعویض لیسکوف
جداسازی رابط
وارونگی وابستگی
هیچ یک از این اصول منحصر به فرد نیستند، زیرا برخی از آنها استراتژی های متعددی را نشان می دهند که یک هدف واحد را دنبال می کنند. یا در موارد دیگر، تبعیت از یک روش SOLID ممکن است به طور طبیعی منجر به دیگری شود.
نمونه هایی از تزریق وابستگی
هنگامی که یک کلاینت برای انجام موفقیت آمیز هدف مورد نظر خود به اجزای دیگری نیاز دارد، کلاینت باید بداند چه منابعی مورد نیاز است، کجا آنها را پیدا کند و چگونه با آنها ارتباط برقرار کند. یکی از راه های ساختاردهی کد، تعبیه منطق برای مکان یابی منابع در هر کلاینت است. با این حال، این رویکرد محکم می تواند مشکل ساز باشد، زیرا اگر منبعی باید مکان خود را تغییر دهد، کد تعبیه شده باید بازنویسی شود.
به عنوان مثال، زمانی که کاربر روی دکمه ای کلیک می کند، رویداد یک نمونه جدید از یک لایه منطق ایجاد می کند و یکی از متدهای رویداد فراخوانی می شود. در داخل آن متد، نمونه جدیدی از کلاس لایه دسترسی به داده نیز تشکیل می شود و یکی از متدهای آن فراخوانی می شود. به نوبه خود، این روش یک کوئری از پایگاه داده ایجاد می کند.
راه دیگر برای ساختار کد این است که کلاینت تان وابستگی خود را به منابع اعلام کنند و یک قطعه کد خارجی را قادر سازد که مسئولیت نمونه سازی و پیکربندی اجزای نرم افزار و وابستگی های آنها را بر عهده بگیرد. قطعه کد خارجی، که جدا شده است، می تواند به صورت دستی کدگذاری شود یا با یک ماژول نرم افزاری خاص به نام ظرف تزریق وابستگی یا چارچوب تزریق وابستگی پیاده سازی شود.
اساساً، کانتینر یا فریمورک نقشهای از وابستگی‌هایی که کلاینت ممکن است به آن نیاز داشته باشد و منطقی برای افزودن وابستگی‌های جدید به نقشه ارائه می‌کند.
این روابط در اصل وارونگی وابستگی خلاصه می‌شوند، که می‌گوید، "ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند؛ هر دو باید به انتزاع‌ها وابسته باشند. انتزاع‌ها نباید به جزئیات بستگی داشته باشند. جزئیات باید به انتزاع‌ها بستگی داشته باشند."
ما همچنین از تزریق وابستگی در Node.js بررسی کردیم می توانید برای کسب اطلاعات بیشتر به آن مراجعه کنید.
روش های تزریق وابستگی
بیش از یک راه برای استفاده از تزریق وابستگی وجود دارد. متداول ترین روش استفاده از تزریق سازنده است، که مستلزم آن است که تمام وابستگی های نرم افزاری هنگام ایجاد یک شی برای اولین بار ارائه شوند. با این حال، تزریق سازنده فرض می‌کند که کل سیستم از این الگوی طراحی نرم‌افزار استفاده می‌کند، به این معنی که کل سیستم باید به طور همزمان بازسازی شود. این سخت، پرمخاطره و وقت گیر است.
یک رویکرد جایگزین برای تزریق سازنده، سرویس یاب(service locator) است، الگویی که طراحان نرم‌افزار می‌توانند آن را به آرامی پیاده‌سازی کنند و برنامه را تکه تکه‌ای در زمان مناسب بازسازی کنند. انطباق آهسته سیستم های موجود بهتر از تلاش های عظیم برای تبدیل است. بنابراین، هنگام تطبیق یک سیستم موجود، تزریق وابستگی از طریق سرویس یاب بهترین الگو برای استفاده است.
کسانی هستند که الگوی مکان یاب سرویس را مورد انتقاد قرار می دهند و می گویند که این الگوی مکان یاب را جایگزین وابستگی ها می کند نه اینکه tight coupling را حذف کند. با این حال، برخی از برنامه نویسان اصرار دارند که هنگام به روز رسانی یک سیستم موجود، استفاده از مکان یاب سرویس در طول انتقال ارزشمند است، و زمانی که کل سیستم با مکان یاب سرویس تطبیق داده شده است، تنها یک مرحله کوچک اضافی برای تبدیل به تزریق سازنده لازم است. .
وارونگی کنترل در مقابل تزریق وابستگی
در حالی که در مورد رابطه بین وارونگی کنترل و تزریق وابستگی سردرگمی و بحث وجود دارد، دومی به طور کلی یکی از سبک های خاص اولی در نظر گرفته می شود.
به گفته مارتین فاولر، دانشمند ارشد Thoughtworks، این سردرگمی به دلیل افزایش کانتینر IoC به وجود می آید. به گفته فاولر، "این نام تا حدودی گیج کننده است زیرا کانتینرهای IoC به طور کلی به عنوان رقیبی برای Enterprise JavaBeans در نظر گرفته می شوند، اما EJB از وارونگی کنترل به همان اندازه استفاده می کند - اگر نه بیشتر."
تزریق وابستگی یک مورد استفاده خاص از IoC را توصیف می کند، موردی که در آن یک کانتینر یک زمینه برنامه قابل تنظیم را فراهم می کند که اشیاء قابل اتصال را ایجاد، شروع، جذب و مدیریت می کند.
انواع تزریق وابستگی
چندین متد مختلف تزریق وابستگی وجود دارد:
تزریق رابط. یک روش تزریقی که توسط یک وابستگی ارائه می شود، وابستگی را به کلاینت دیگر تزریق می کند. سپس کلاینت ها باید رابطی را پیاده سازی کنند که از یک متد setter برای پذیرش وابستگی استفاده می کند.
تزریق سازنده. یک انژکتور با استفاده از سازنده کلاس کلاینت یک وابستگی ایجاد می کند. هنگامی که یک شی کلاس ایجاد می شود استفاده می شود.
تزریق ستر (Setter injection). یک injector یک وابستگی با استفاده از متد setter فراهم می کند که مقدار متغیر نمونه خصوصی کلاس را تنظیم و تغییر می دهد.
متد تزریق یک کلاس کلاینت برای پیاده سازی یک رابط استفاده می شود. سپس یک متد وابستگی را فراهم می کند و یک انژکتور از رابط برای تامین وابستگی به کلاس استفاده می کند.
جهت بررسی تزریق وابستگی و Service Container در لاراول می توانید این مقاله را مطالعه کنید.
چالش های استفاده از Dependency Injection
همانطور که Dependency Injection قدرتمند است، یک چیز بدون عیب و نقض نیست. مانند هر رویکرد دیگری، مشکلاتی دارد که توسعه دهندگان باید از آن آگاه باشند. در اینجا، به چند چالش رایج مرتبط با تزریق وابستگی می پردازیم و توصیه هایی برای غلبه بر آنها ارائه می دهیم.
1. Overcomplication
یکی از رایج‌ترین مشکلاتی که توسعه‌دهندگان در آن قرار می‌گیرند، استفاده بیش از حد از Dependency Injection است که می‌تواند منجر به یک سیستم بیش از حد پیچیده شود. این معمولاً زمانی اتفاق می‌افتد که توسعه‌دهندگان سعی می‌کنند Dependency Injection را برای کلاس‌هایی اعمال کنند که وابستگی ندارند یا نیازی به تعویض ندارند.
راه حل: به یاد داشته باشید که تزریق وابستگی یک ابزار است و تنها زمانی باید از آن استفاده کرد که مشکلی را حل کند. اگر کلاسی وابستگی ندارد یا نیازی به پیاده سازی های مختلف ندارد، بهتر است آن را تزریق نکنید.
2. سوء مدیریت طول عمر اشیا
سوء تفاهم یا مدیریت نادرست طول عمر تزریق وابستگی می تواند منجر به مشکلات شدیدی مانند نشت بین درخواست ها یا نشت حافظه شود.
راه حل: برای درک تفاوت بین طول عمر Transient، Scoped و Singleton وقت بگذارید و بر اساس نیازهای برنامه خود، مناسب را انتخاب کنید.
3. مشکلات با سلسله مراتب عمیق کلاس
هنگام کار با سلسله مراتب طبقاتی عمیق، مدیریت وابستگی ها می تواند مشکل ساز شود. معمول است که سازنده‌ها را با وابستگی‌های متورم ببینیم، که می‌تواند خواندن و نگهداری کد را سخت‌تر کند.
راه حل: اگر کلاسی شروع به وابستگی های بیش از حد کند، ممکن است نشانه آن باشد که کلاس بیش از حد کار می کند و اصل تک مسئولیتی را نقض می کند. بازسازی کلاس و تقسیم مسئولیت های آن بین چندین کلاس کوچکتر و متمرکزتر را در نظر بگیرید.
4. مشکلات با تست واحد
در حالی که Dependency Injection یک مزیت برای تست واحد است، اگر به درستی اجرا نشود می‌تواند مشکلاتی ایجاد کند. وابستگی هایی که به درستی انتزاع نشده اند می توانند جایگزینی آنها با پیاده سازی های ساختگی برای تست را دشوار کنند.
راه حل: همیشه به انتزاعات بستگی داشته باشید، نه به اجرای عینی. اطمینان حاصل کنید که وابستگی ها را با استفاده از رابط ها یا کلاس های انتزاعی انتزاعی کنید، که امکان جایگزینی آسان با پیاده سازی های ساختگی در طول تست را فراهم می کند.
با رفع این چالش ها و Cyclic Dependencies و Over-Injection می توانید از قدرت تزریق وابستگی بهره مند شوید.
Service Locator چیست؟
ایده اصلی Service Locator این است که یک رجیستری حاوی تمام وابستگی ها ایجاد کنیم و هر زمان که به آنها نیاز داشتیم از آن اجزا دریافت کنیم. هر شیئی که به چیزی از این رجیستری نیاز دارد، به جای تلاش برای ایجاد یک وابستگی، با آن تعامل خواهد داشت. به این ترتیب، می‌توانیم تمام وابستگی‌های پیاده‌سازی concrete را از اجزای خود حذف کنیم.
با این حال، شی همچنان یک وابستگی خواهد داشت، اما فقط برای خود Service Locator، و پیاده سازی مورد نیاز را به صورت شفاف در اختیار ما قرار می دهد. متأسفانه، بیش از حد شفاف است زیرا تمام وابستگی ها را از کلاینت پنهان می کند. از نظر فنی، کپسولاسیون را می شکند، زیرا هر گونه تعامل با یک شی مستلزم نگاه کردن به اجزای داخلی است، مخصوصاً در هنگام تست.
مشکل دیگر این است که Service Locator خطاهای زمان کامپایل را به زمان اجرا موکول می کند. استفاده مستقیم از Service Locator در متدها مشکل مهم تری ایجاد می کند. از آنجایی که رجیستری Service Locator در زمان اجرا پر می شود، تشخیص اینکه آیا کلاس های مورد نیاز زمانی که ما آنها را درخواست می کنیم وجود خواهند داشت یا خیر دشوار است. کانتینر تزریق وابستگی ممکن است همین مشکل را برای قطعات پویا ایجاد شده بعداً در چرخه عمر برنامه ایجاد کند.
همچنین، Service Locator اصل جداسازی رابط را نقض می کند. با این حال، این موضوع قابل بحث است زیرا خود «رجیستری» ممکن است بخشی از فرابرنامه‌نویسی در نظر گرفته شود و اصول طراحی معمول باید با احتیاط اعمال شوند.
برخلاف Service Locator، یک Abstract Factory و یک Factory وابستگی های خود را به وضوح بیان می کنند.
علاوه بر این، مردم به مشکل تست‌پذیری اشاره می‌کنند، اما اگر Service Locator به اندازه کافی انعطاف‌پذیر باشد، مشکل واقعی نیست. در بیشتر موارد، اگر Service Locator به عنوان Singleton پیاده‌سازی شود یا راه ساده‌ای برای پیکربندی رجیستری اجازه ندهد، مشکل پیش می‌آید.
Service Locator به یک مکان اختصاصی برای پر کردن رجیستری با اجزا نیاز دارد. به این ترتیب می‌توانیم منطق ایجاد را از کلاس‌هایی که از آنها استفاده می‌کنند جدا کنیم. این جداسازی ضروری است، به خصوص اگر یک نمودار وابستگی پیچیده داشته باشیم.
تزریق وابستگی در مقابل سرویس یاب
یکی از تفاوت های اصلی این رویکردها، شفافیت آنها در مورد وابستگی هایی است که معرفی می کنند. Dependency Injection در مورد هر چیزی که در یک کلاس استفاده می‌شود، واضح است و با تزریق سازنده، به وضوح در API کلاس نشان داده می‌شود. در حالی که Service Locator همه چیز را در داخل پنهان می کند، و تشخیص اینکه کدام کلاس ها به کدام یک بستگی دارند دشوار است، تنها چیزی که واضح است همه آنها به Service Locator بستگی دارند. پیاده سازی Service Locator با رابط های جدا شده امکان پذیر است، اما ممکن است منجر به مشکلاتی در رابط شود. اگرچه IDE مدرن می تواند نمودارهای وابستگی را نشان دهد و نمودارهای UML واضح بسازد، API وابستگی ها را نمی شناسد.
نکته دیگر این است که Dependency Injection نفوذ کمتری دارد و امکان استفاده مجدد را می دهد. کلاس‌ها مستقیماً به کلاس‌های دیگر وابسته هستند و به آنها اجازه می‌دهد به درستی کار کنند. با Service Locator، تنها راه برای استفاده مجدد از کلاس ها استفاده مجدد از آنها با خود Service Locator است. بنابراین، آنها در یک بسته می روند. حتی اگر هر دو الگو به کلاس‌هایی که اشیاء برنامه را می‌سازند و پیکربندی می‌کنند متکی هستند، تزریق وابستگی امکان استفاده مجدد بهتر و تست ساده‌تر را می‌دهد.
به طور کلی، Dependency Injection روش رایج برای دستیابی به اتصال شل و اجازه استفاده مجدد از اجزا است. این بسیار شهودی است و به ما امکان می دهد وابستگی ها را به طور واضح تری اعلام کنیم. Service Locator می‌تواند انعطاف‌پذیری بیشتر و اغلب بیش از حد را فراهم کند. این انعطاف‌پذیری گسترده می‌تواند تمام مرزهای بین اجزا را بشکند و اقدامات بد را تشویق کند، زیرا همه مؤلفه‌ها همیشه در دسترس هستند، هر زمان که به آنها نیاز داشته باشیم. Service Locator اغلب می تواند یک ضد الگو در نظر گرفته شود، زیرا ممکن است مشکلات و کد بیشتری را نسبت به مزایا ایجاد کند.
نتیجه
اصل وارونگی وابستگی SOLID، رابط هایی را بین یک کلاس سطح بالاتر و وابستگی های آن معرفی می کند. که کلاس سطح بالاتر را از وابستگی های آن جدا می کند تا بتوانید کد یک کلاس سطح پایین تر را بدون تغییر کدی که از آن استفاده می کند تغییر دهید. تنها کدی که مستقیماً از یک وابستگی استفاده می کند، کدی است که یک شی از یک کلاس خاص را که رابط را پیاده سازی می کند، نمونه سازی می کند.
تکنیک تزریق وابستگی شما را قادر می سازد تا این را حتی بیشتر بهبود بخشید. این روشی را برای جدا کردن ایجاد یک شی از استفاده از آن فراهم می کند. با انجام این کار، می توانید یک وابستگی را بدون تغییر هیچ کدی جایگزین کنید و همچنین کد دیگ بخار را در منطق کسب و کار شما کاهش می دهد.