مفاهیم IoC، DIP و DI در برابر هم

متاسفانه سه مفهوم زیر در متون، مقالات و محاوره ها به اشتباه استفاده شده و برای عمده افراد این سه عبارت معانی یکسانی دارند. اما به راستی چه تفاوتی بین عبارات زیر وجود دارد:
1. Inversion Of Control یا IoC یا Hollywood Principle
2. Dependency Inversion Principle یا DIP
3. Dependency Injection یا DI

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

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

فریم در مفهوم کلان می تواند چیزی مانند دات نت فریم ورک باشد و یا چیزی مانند Windows Froms، WPF و یا ASP.NET MVC و غیره باشد. مفهوم IoC در طراحی فریم ورک به این معنا است که قابلیتی را برای استفاده کنندگان از فریم ورک فراهم کنیم تا در مواقع لزوم، در حین تغییر وضعیت، در حین رخداد ها و ... بتوانند با کدهای شان دستوری را برای فریم ورک صادر کنند و یا تغییری در نحوه کارکرد فریم ورک بدهند و یا از تغییری در وضعیت سیستم مطلع شوند. چیزی که باعث می شود این امر معکوس سازی کنترل خوانده شود آن است که در این روش، فریم ورک به طور خودکار، در مواقع تعریف شده، کدهای کاربر را صدا می زند و اجرا می کند. 

در مثالی خیلی ساده، می توانیم بگوییم در کار با Windows Form، ما مسئولیت اصلی برنامه را به این فریم ورک می سپاریم و صرفا با مشخص کردن کدهای مربوط به رخدادهای مربوط به دکمه ها و .... از فریم ورک می خواهیم در مواقعی که لازم بود، کد های ما را فراخوانی کند.

یکی دیگر از موارد مشخص استفاده از IoC جاهایی است که فریم ورک متد هایی را تحت عنوان Callback دریافت می کند.

در مثال های پیشرفته تر می توانیم کلاس هایی تعریف کنیم و کلاس هایمان را با کلاس های داخلی فریم ورک تعویض کنیم. مثلا در ASP.NET MVC می توانیم رفتار بسیاری از قسمت های فریم ورک را مطابق خواستمان شخصی سازی کنیم و بدانیم فریم ورک از کلاس های ما استفاده خواهد کرد و در مواقع لزوم کدهای ما را صدا خواهد زد.

همچین الگوهای Template Method و یا Strategy و Factory به کرات در این امر مورد استفاده قرار می گیرند و مطمئن باشید، بدون اینکه مطلع باشید، بار ها از این موارد استفاده کرده اید.

پس IoC چیزی نیست جز این امر بدیهی نیست که فریم ورک به گونه ای توسعه داده شده است که می تواند در مواقع لزوم کدهای ما را صدا بزند و اینگونه رفتار اش را تغییر بدهد و یا Extend شود. به همین خاطر به این اصل Hollywood Principle هم گفته می شود و شعار اش این است:
Dont Call Us, We Will Call You

http://martinfowler.com/bliki/InversionOfControl.html