هدف من در این مقاله، آشنایی شما با چهارمین اصل از اصول، یعنی یا است. اصل DIP بیان میکند: بنابراین میتوان گفت، این اصل از سه جز تشکیل شده است: کلاس های سطح بالای ما، نباید به کلاس های سطح پایین وابستگی داشته باشند. وابستگی کلاس های سطح بالا، و کلاس های سطح پایین ما باید به abstraction باشد. این abstraction نیست که به جزییات وابستگی دارد، بلکه جزییات هستند که به abstraction وابسته اند. به این مثال توجه کنید: هر چند میتوانیم تابع" CalculateSalary " را به این صورت بنویسیم: اما از آنجایی که در زمان دیباگ، امکان trace کردن روند محاسبه و نتیجه ی نهایی را نداریم، از این امکان استفاده نمیکنیم. می بینید که برای محاسبه ی حقوق کارمندان، باید از کلاس" SalaryCalculator " یک آبجکت ساخته و با فراخوانی متد" CalculateSalary " آن، حقوق کارمند مورد نظر را محاسبه کنیم (این یعنی) : مثال بالا، نمونه ی بارز نقض ست، چرا که (با این روش پیاده سازی) کلاس سطح بالای ما (یعنی " EmployeeDetails ") ، به کلاس سطح پایین ما (یعنی " SalaryCalculator ") وابسته شده است. اما چگونه میتوان این مشکل را برطرف کرد؟ بیایید دوباره اصل Dependency Inversion را با هم مرور کنیم: برای رفع این مشکل، ما (یا ی) ایجاد کرده، و متد" CalculateSalary " را (با پارامترهای ورودی و خروجی مشخص شده) در آن تعریف می نماییم: کلاس" SalaryCalculator " به عنوان کسی که از اینترفیس" ISalaryCalculator " ارث بری کرده، موظف به پیاده سازی موجودات تعریف شده در آن است: همانطور که میبینید، وابستگی ما دیگر به کلاس" SalaryCalculator " نیست، و به اینترفیس" ISalaryCalculator " (یا اصطلاحا شده است. این بدان معناست که ما دیگر با این که چه کسی متد" CalculateSalary " را پیاده سازی کرده است، کاری نداریم و صرفا با لایه ی abstract آن در ارتباط هستیم.