التكنولوجيا
البرمجة
تطوير البرمجيات
برمجة موجهة نحو الكائنات
حقن التبعية
تناوب التحكم
الحقن التكويني
هنيكية البرنامج
سلسلة الأوامر
الDependency Injection اصبحت من المفاهيم المهمة في عالم البرمجة الشيئية OOP وهي ليست بالجديدة لكن تبنّي الكثير من اللغات لها هو ماجعلها مشهورة هذه الأيام. لكن ما أهميتها ؟ و ماعلاقتها بالIoC و مبدأ الDI و الPlugin Architecture ؟ و قبل ذلك من أين اتت؟
(سلسلة)
(سلسلة)
أي منشأة تجارية او خدمية يكون لها في العادة هيكل اداري يُمثل مستويات ادارية . هذا الهيكل قد يبدأ ( في منشأة صغيرة ) من مدير عام ثم يتفرع نزولاً إلى مدراء ادارات ثم إلى موظفين ( هم من يقومون بالعمل الفعلي ).
هذه التراتبية تثمثّل تسلسل اسناد السلطات من الأعلى إلى الأسفل و بالانجليزية Chain of Command. فمثلاً عندما يطلب مدير عام من مدير ادارة اداء عمل ما, و يقوم مدير الإدارة باختيار أحد موظفينه لأداء ذلك العمل. هنا حدثت عملية تفويض!.
لاحظ أن المدير العام لم يحدد الموظف لكن التحديد تم اثناء التنفيذ من قبل مدير الإدارة . ما يهم في الاخير أن من قام بالعمل هو الموظف. و بالنسبة للمدير العام فمدير الادارة هو من انجز العمل و لا يهمه من نفّذ العمل فعلياً. مدير الادارة هنا عمل كـ Interface و Injector في نفس الوقت
هذا المبدأ هو نفس المبدأ الذي يسمى مبدأ هوليوود , "لا تتصل بنا , نحن سنتصل بك". في اشارة إلى من يتقدم للتمثيل في افلام هوليوود. و كأن مدير الإدارة اخذ الكونترول من المدير العام فهو من اختار الموظف المناسب الذي سوف يقوم بالمهمه و يعالج اي قصور و من ثم يخبر المدير العام باكتمالها.
هذا ما يُقصد بالIoC اختصار Inversion of Control. عملية الإسناد الحقيقي تأتي لاحقاً اثناء التشغيل و ليس لحظياً في عند كتابة الكود ( أمر العمل ) . هذا امر تختص به الOOP فقط.
في الStructured و الProcedural Paradigms قبل الOOP كانت الأمور لا تسير هكذا, أي ان المدير العام ولنقل هنا انه الMain Method يعرف تماماً أي Method ينادي لعمل خدمة معينه له, و قد يطلب الMethod المدعو ايضاً Method ثالث و هكذا ... الترابط وثيق فلو عجز الموظف المعيّن فشلت العملية.
هذه الطريقة اشبه بعندما يقوم المدير العام بتخطي من هم تحته إلى الموظف مباشرة, فلو تغيّب الموظف او لم يستطع اكمال المهمة لسبب ما فسيكون المدير العام في ورطه. بعكس الطريقة الأولى التي اسندها لمن تحته مباشره أي مدير الإدارة و الذي بدوره سيقوم بما يلزم لتدارك اي قصور و توفير البديل.
مبدأ الIoC يعود للثمانينات كأساس في لغة Smalltalk اللغة الOOP و لعل هذا المبدأ كما ذكرت هو ما يميز حقيقة الOOP عن غيرها من الParadigms وليس الأعمدة الثلاثه المعروفه للOOP. فتلك الطريقة لم تكن ممكنة في الـ Paradigms السابقة للOOP بما فيها الFunctional Programming (تقريباً)
لنأخذ مثال واقعي: عندما نطبع صفحة موقع من المتصفح , يظهر لنا المتصفح جميع الطابعات المتصلة. كيف سيتم ذلك لو كان على المتصفح أن يعرف كل انواع الطابعات في العالم و يرتبط مباشره بها ؟ هل تعاملت مع برامج تدعم الPlugins ؟ هي نفس التقنية. لننتقل الآن الى الDependency Injection.
مفهوم الIoC اعمق و اشمل من مفهوم الDependency Injection و الخلط بين المفهومين موجود حتى عند مبرمجين كبار. فمارتن فاولر مثلا ساوى بينهما الذي اعاد تسمية الIoC بـ DI. فالIoC هدفه الفصل اما الDI فهو مجرد وسيلة لتحقيق الIoC كما علق عليه من اضاف تلك الخاصية في لجافا Stefano Mazzochi.
و الدليل أن هناك طرق كثيرة للDI مثل الContextualized Dependency Lookup و ال Properties DI و الConstructor DI و هو الاشهر. في اغلب اللغات الحية الآن يتم تحقيق الIoC من خلال الFactory Pattern و بمساعدة خاصية الReflection في اللغة.
في الدوت نت مثلاً كنت تحتاج إلى مكتبة خارجية مثل Ninject او Unity اما الآن فاصبح جزء من net core. او مثل Spring IoC Container لجافا. هذه النوع من المكتبات هو مايعرف بالDependency Injection Containers
نقطة اخيرة : استخدام هذه التقنية هو تحقيق للمبدأ الخامس من مباديء SOLID و هو الDIP اختصار Dependency Inversion Principle.
اعتذر على عدم وضع امثلة للأكواد لاختلاف اللغات التي يعمل عليها المتابعين لكن هذه السلسة ستجعل الموضوع اسهل للفهم فيما لو قرأت عن تلك المفاهيم المذكورة و تطبيقها بلغتك. على الأقل عرفت الترابط بينها و وضعت امامك الكلمات التي عليها البحث عنها.
جاري تحميل الاقتراحات...