oop - ما هو انعكاس التحكم؟




design-patterns inversion-of-control (20)

  1. انقلاب التحكم هو نمط يستخدم لفصل مكونات وطبقات النظام. يتم تنفيذ النمط من خلال حقن التبعيات في أحد المكونات عند إنشائه. عادةً ما يتم توفير هذه التبعيات كواجهات لمزيد من الفصل ولتعزيز القابلية للاختبار. حاويات IoC / DI مثل Castle Windsor، Unity هي أدوات (مكتبات) يمكن استخدامها لتوفير IoC. توفر هذه الأدوات ميزات موسعة تتجاوز إدارة التبعية البسيطة ، بما في ذلك العمر ، AOP / اعتراض ، السياسة ، إلخ.

  2. ا. يخفف المكون من كونه مسؤولاً عن إدارة تبعياته.
    ب. يوفر القدرة على تبديل تطبيقات التبعية في بيئات مختلفة.
    ج. يسمح لاختبار عنصر من خلال الاستهزاء بالتبعيات.
    د. يوفر آلية لمشاركة الموارد عبر التطبيق.

  3. ا. الحرجة عند القيام اختبار يحركها التنمية. بدون اختبار IoC ، قد يكون من الصعب اختباره ، لأن المكونات قيد الاختبار مرتبطة بشكل كبير ببقية النظام.
    ب. حرجة عند تطوير أنظمة وحدات. النظام المعياري هو نظام يمكن استبدال مكوناته دون الحاجة إلى إعادة تجميع.
    ج. حرجة إذا كان هناك العديد من المخاوف الشاملة التي تحتاج إلى معالجة ، جزئيا في تطبيق المؤسسة.

يمكن أن يكون انقلاب التحكم (أو IoC) مربكًا للغاية عند مواجهته لأول مرة.

  1. ما هذا؟
  2. ما المشكلة التي تحلها؟
  3. متى يكون مناسبًا للاستخدام ومتى لا؟

  1. ويكيبيديا المادة . بالنسبة لي ، فإن قلب التحكم يحول كودك المكتوب بالتسلسل ويحوله إلى بنية تفويض. بدلاً من أن يتحكم البرنامج في كل شيء بشكل صريح ، يقوم البرنامج بإعداد فصل دراسي أو مكتبة مع وظائف معينة ليتم استدعاؤها عند حدوث أشياء معينة.

  2. يحل الازدواجية رمز. على سبيل المثال ، في الأيام القديمة ، كنت تكتب حلقة الأحداث الخاصة بك يدويًا ، حيث تقوم باستقصاء مكتبات النظام للأحداث الجديدة. في الوقت الحاضر ، تقوم معظم واجهات برمجة التطبيقات الحديثة بإخبار مكتبات النظام ببساطة عن الأحداث التي تهتم بها ، وسوف تتيح لك معرفة وقت حدوثها.

  3. انقلاب التحكم هو طريقة عملية لتقليل ازدواجية التعليمات البرمجية ، وإذا وجدت نفسك تقوم بنسخ طريقة بأكملها وتغيير جزء صغير فقط من الكود ، فيمكنك التفكير في التعامل معها من خلال عكس عنصر التحكم. يتم إجراء عكس التحكم بسهولة في العديد من اللغات من خلال مفهوم المفوضين أو الواجهات أو حتى مؤشرات الوظائف الأولية.

    ليس من المناسب استخدامها في جميع الحالات ، لأن تدفق البرنامج قد يكون من الصعب متابعته عند كتابته بهذه الطريقة. إنها طريقة مفيدة لتصميم الأساليب عند كتابة مكتبة سيتم إعادة استخدامها ، ولكن يجب استخدامها بشكل بسيط في لب البرنامج الخاص بك ما لم تحل بالفعل مشكلة تكرار التعليمات البرمجية.


IoC / DI بالنسبة لي هو دفع التبعيات إلى كائنات الدعوة. سوبر بسيط.

الإجابة غير الفنية هي القدرة على تبديل محرك في سيارة قبل تشغيله مباشرة. إذا كان كل شيء يصل إلى اليمين (الواجهة) ، فأنت جيد.


إن انعكاس التحكم ، أو (IoC) ، يدور حول الحصول على الحرية (أنت تتزوج ، تضيع الحرية وتُسيطر عليك. أنت مطلقة ، لقد قمت للتو بتطبيق "انعكاس التحكم". هذا ما أطلقنا عليه "فك الارتباط". نظام كمبيوتر جيد لا يشجع بعض العلاقات الوثيقة جدًا.) مزيد من المرونة (يقدم المطبخ الموجود في مكتبك مياه الصنبور النظيفة فقط ، وهذا هو خيارك الوحيد عندما تريد أن تشرب. قام رئيسك بتطبيق Inversion of Control من خلال إعداد ماكينة قهوة جديدة. الآن يمكنك الحصول على المرونة في اختيار إما ماء الصنبور أو القهوة.) وتقليل التبعية (شريكك لديه وظيفة ، ليس لديك وظيفة ، تعتمد ماليًا على شريكك ، لذا فأنت خاضع للتحكم. يمكنك العثور على وظيفة ، وقد قمت بتنفيذ Inversion of التحكم. نظام الكمبيوتر الجيد يشجع التبعية.)

عندما تستخدم جهاز كمبيوتر سطح مكتب ، فإنك تكون مستعبداً (أو قل ، مسيطرًا). يجب عليك الجلوس أمام الشاشة والنظر إليها. استخدام لوحة المفاتيح لكتابة واستخدام الماوس للتنقل. والبرنامج المكتوب بشكل سيء يمكن أن يعبدك أكثر. إذا قمت باستبدال سطح المكتب الخاص بك بجهاز كمبيوتر محمول ، فأنت بذلك تحكم مقلوب إلى حد ما. يمكنك أن تأخذ بسهولة وتتحرك. يمكنك الآن التحكم في مكانك باستخدام الكمبيوتر ، بدلاً من التحكم في جهاز الكمبيوتر الخاص بك.

من خلال تطبيق Inversion of Control ، يحصل مستهلك البرنامج / الكائن على مزيد من عناصر التحكم / الخيارات على البرنامج / الكائنات ، بدلاً من التحكم أو الحصول على خيارات أقل.

مع الأفكار المذكورة أعلاه في الاعتبار. ما زلنا نفتقد جزء رئيسي من IoC. في سيناريو IoC ، يعتبر مستهلك البرنامج / الكائن إطارًا متطورًا. هذا يعني أن الكود الذي قمت بإنشائه لا يسمى بنفسك. الآن دعنا نوضح لماذا تعمل هذه الطريقة بشكل أفضل لتطبيق ويب.

افترض أن الكود الخاص بك هو مجموعة من العمال. انهم بحاجة الى بناء سيارة. يحتاج هؤلاء العمال إلى مكان وأدوات (إطار عمل برمجي) لبناء السيارة. سيكون إطار البرنامج التقليدي مثل المرآب مع العديد من الأدوات. لذلك يحتاج العمال إلى وضع خطة بأنفسهم واستخدام الأدوات اللازمة لبناء السيارة. بناء السيارة ليس بالأمر السهل ، سيكون من الصعب على العمال التخطيط والتعاون بشكل صحيح. سيكون إطار البرامج الحديثة مثل مصنع السيارات الحديثة مع جميع المرافق والمديرين في المكان. لا يتعين على العمال وضع أي خطة ، وسيساعد المديرون (جزءًا من الإطار ، وهم أذكى الأشخاص وصنعوا الخطة الأكثر تطوراً) في التنسيق حتى يعرف العمال متى يقومون بعملهم (إطار العمل يستدعي الرمز الخاص بك). يحتاج العمال فقط إلى التحلي بالمرونة الكافية لاستخدام أي أدوات يقدمها المديرون لهم (باستخدام Dependency Injection).

على الرغم من إعطاء العمال السيطرة على إدارة المشروع على المستوى الأعلى للمديرين (الإطار). ولكن من الجيد أن يساعد بعض المحترفين في ذلك. هذا هو مفهوم IoC يأتي حقا من.

تعتمد تطبيقات الويب الحديثة ذات بنية MVC على إطار عمل توجيه URL ووضع أدوات التحكم في مكانها حتى يتسنى للإطار الاتصال.

ترتبط حقن التبعية وانقلاب التحكم. Dependency Injection في المستوى الجزئي وانقلاب التحكم في المستوى الكلي . عليك أن تأكل كل لقمة (تنفذ DI) من أجل الانتهاء من تناول وجبة (تنفيذ IoC).


الرد فقط الجزء الأول. ما هذا؟

يعني "انعكاس التحكم" (IoC) إنشاء مثيلات التبعيات أولاً والمثيل الأخير لفئة (عن طريق الحقن اختياريًا من خلال المُنشئ) ، بدلاً من إنشاء مثيل للفئة أولاً ثم المثيل فئة الذي ينشئ مثيلات التبعيات. وبالتالي ، فإن عكس التحكم يؤدي إلى عكس تدفق التحكم في البرنامج. بدلاً من التحكم في تدفق التحكم (أثناء إنشاء التبعيات) ، يتحكم المتصل في تدفق التحكم في البرنامج .


انعكاس عناصر التحكم يدور حول فصل المخاوف.

بدون IoC : لديك كمبيوتر محمول وتكسر الشاشة عن طريق الخطأ. و darn ، تجد شاشة الكمبيوتر المحمول نفس النموذج في أي مكان في السوق. لذلك أنت عالق.

مع IoC : لديك جهاز كمبيوتر سطح مكتب وتكسر الشاشة عن طريق الخطأ. تجد أنه يمكنك فقط الحصول على أي شاشة سطح مكتب تقريبًا من السوق ، وهي تعمل بشكل جيد مع سطح المكتب.

ينفذ سطح المكتب الخاص بك بنجاح IoC في هذه الحالة. إنه يقبل نوعًا مختلفًا من الشاشات ، بينما لا يحتاج الكمبيوتر المحمول إلى شاشة محددة حتى يتم إصلاحه.


دعنا نقول أننا نجعل بعض الاجتماعات في بعض الفنادق.

كثير من الناس ، العديد من قوارير الماء ، العديد من الأكواب البلاستيكية.

عندما يريد شخص ما أن يشرب ، تملأ الكأس ، تشرب وتلقي الكأس على الأرض.

بعد ساعة أو أي شيء لدينا أرضية مغطاة بأكواب بلاستيكية وماء.

اسمحوا عكس السيطرة.

نفس الاجتماع في نفس المكان ، ولكن بدلاً من الأكواب البلاستيكية لدينا نادل مع كوب زجاجي واحد (Singleton)

وقالت انها تقدم في كل وقت للضيوف الشرب.

عندما يريد شخص ما أن يشرب ، فإنها تحصل عليه من كأس النادل ، تشربه وتعيده إلى النادل.

إذا وضعنا جانباً مسألة الصحة ، فإن الشكل الأخير للتحكم في عملية الشرب هو أكثر فعالية واقتصادية.

وهذا بالضبط ما يفعله Spring (حاوية IoC أخرى ، على سبيل المثال: Guice). بدلاً من السماح للتطبيق بإنشاء ما يحتاج إليه باستخدام كلمة أساسية جديدة (أخذ كوب من البلاستيك) ، توفر حاوية Spring IoC طوال الوقت لتطبيق نفس مثيل الكائن المنفرد (كوب من الماء).

فكر في نفسك كمنظم لهذا الاجتماع. أنت في حاجة إلى رسالة إلى إدارة الفندق

سيحتاج أعضاء الاجتماع إلى كوب من الماء ولكن ليس قطعة من الكعكة.

مثال:-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

روابط مفيدة:-


على سبيل المثال ، المهمة رقم 1 هي إنشاء كائن. بدون مفهوم IOC ، من المفترض أن يتم تنفيذ المهمة رقم 1 بواسطة Programmer.But مع مفهوم IOC ، سيتم تنفيذ المهمة رقم 1 بواسطة الحاوية.

باختصار ، يتم قلب التحكم من المبرمج إلى الحاوية. لذلك ، يطلق عليه انعكاس السيطرة.

لقد وجدت مثالا جيدا here .


كل من انقلاب التحكم (IoC) وأنماط حقن التبعية (DI) كلها تتعلق بإزالة التبعيات من الكود.

على سبيل المثال ، لنفرض أن التطبيق الخاص بك يحتوي على مكون محرر نص وتريد تقديم التدقيق الإملائي. سيبدو الرمز القياسي الخاص بك كما يلي:

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

ما قمنا به هنا يخلق تبعية بين TextEditor و SpellChecker . في سيناريو IoC ، سنفعل شيئًا مثل هذا:

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

في المثال الأول من التعليمات البرمجية ، نقوم بإنشاء مثيل لـ this.checker = new SpellChecker(); ( this.checker = new SpellChecker(); ) ، مما يعني أن فئة TextEditor تعتمد مباشرةً على فئة SpellChecker .

في مثال التعليمة البرمجية الثانية ، نقوم بإنشاء تجريد عن طريق الحصول على فئة التبعية SpellChecker في توقيع مُنشئ TextEditor (وليس تهيئة التبعية في الفصل). هذا يتيح لنا استدعاء التبعية ثم تمريرها إلى فئة TextEditor مثل:

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

الآن لدى العميل الذي ينشئ فئة TextEditor التحكم في تطبيق SpellChecker الذي يجب استخدامه لأننا نحقن التبعية في توقيع TextEditor .


لكنني أعتقد أن عليك أن تكون حذرا للغاية معها. إذا كنت ستفرط في استخدام هذا النمط ، فستقوم بتصميم معقد للغاية ورمز أكثر تعقيدًا.

كما هو الحال في هذا المثال مع TextEditor: إذا كان لديك SpellChecker واحد فقط ، فليس من الضروري حقًا استخدام IoC؟ إلا إذا كنت بحاجة إلى كتابة اختبارات وحدة أو شيء ...

على أي حال: أن تكون معقولة. نمط التصميم هو ممارسات جيدة ولكن ليس الكتاب المقدس الذي يتم التبشير به. لا تلتصق بها في كل مكان.


وأنا أتفق مع NilObject ، لكنني أود أن أضيف إلى هذا:

إذا وجدت نفسك تقوم بنسخ طريقة بأكملها وتغيير جزء صغير فقط من الكود ، فيمكنك التفكير في معالجتها عن طريق قلب التحكم

إذا وجدت نفسك تقوم بنسخ ولصق الكود ، فأنت دائمًا ما تفعل شيئًا خاطئًا. مقننة كمبدأ التصميم مرة واحدة فقط .


يبدو أن الشيء الأكثر إرباكًا حول "IoC" في الاسم المختصر والاسم الذي تمثله هو أنها براقة جدًا في الاسم - اسم ضجيج تقريبًا.

هل نحن حقًا بحاجة إلى اسم لوصف الفرق بين البرمجة الإجرائية وبرامج الأحداث؟ حسنًا ، إذا كنا بحاجة إلى ذلك ، لكن هل نحتاج إلى اختيار اسم جديد "أكبر من الحياة" يربك أكثر مما يحل؟


سأكتب فهمي البسيط لهذه المصطلحين:

For quick understanding just read examples*

حقن التبعية (DI):
حقنة التبعية تعني عمومًا تمرير كائن تعتمد عليه الطريقة ، كمعلمة إلى طريقة ، بدلاً من جعل الطريقة تنشئ الكائن التابع .
ما يعنيه في الممارسة العملية هو أن الطريقة لا تعتمد مباشرة على تنفيذ معين ؛ يمكن تنفيذ أي تطبيق يلبي المتطلبات كمعلمة.

مع هذه الكائنات اقول التبعيات الخاصة بهم. والربيع يجعلها متاحة.
وهذا يؤدي إلى تطوير التطبيق إلى جانب فضفاضة.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

انقلاب حاوية التحكم (IoC):
هذا هو سمة مشتركة من الأطر ، IOC تدير كائنات جافا
- من الإقلاع إلى التدمير من خلال BeanFactory.
تسمى مكونات Java التي يتم إنشاء مثيل لها بواسطة حاوية IoC ، beans ، وتدير حاوية IoC نطاق حبة ، وأحداث دورة حياة ، وأي ميزات AOP تم تكوينها وترميزها.

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it .

من خلال تطبيق Inversion of Control ، يحصل مستهلك البرنامج / الكائن على مزيد من عناصر التحكم / الخيارات على البرنامج / الكائنات ، بدلاً من التحكم أو الحصول على خيارات أقل.

يخدم عكس التحكم كدليل تصميم للأغراض التالية:

يوجد فصل لتنفيذ مهمة معينة من التنفيذ.
يمكن لكل وحدة التركيز على ما تم تصميمه ل.
لا تقدم الوحدات أي افتراضات حول ما تفعله الأنظمة الأخرى ولكنها تعتمد على عقودها.
استبدال الوحدات ليس له أي تأثير جانبي على الوحدات الأخرى
سأبقي الأشياء مجردة هنا ، يمكنك زيارة الروابط التالية لفهم التفاصيل للموضوع.
قراءة جيدة مع المثال

شرح مفصل


لقد قرأت الكثير من الإجابات على هذا ولكن إذا كان شخص ما لا يزال في حيرة من أمره ويحتاج إلى "مصطلح للشخص العادي" بالإضافة إلى شرح IoC هنا ، فأنا أفعل ذلك:

تخيل أحد الوالدين والطفل يتحدث مع بعضهم البعض.

بدون IoC:

* الأصل : لا يمكنك التحدث إلا عندما أطرح عليك أسئلة ويمكنك فقط التصرف عندما أعطيك الإذن.

الوالد : هذا يعني أنه لا يمكنك أن تسألني إذا كان يمكنك تناول الطعام أو اللعب أو الذهاب إلى الحمام أو حتى النوم إذا لم أطلب منك ذلك.

الأم : هل تريد أن تأكل؟

الطفل : رقم

الأم : حسنًا ، سأعود. الانتظار لي.

الطفل : (يريد اللعب ولكن نظرًا لعدم وجود سؤال من الوالد ، لا يمكن للطفل فعل أي شيء).

بعد 1 ساعة...

الأم : لقد عدت. هل تريد أن تلعب؟

الطفل : نعم.

الأصل : تم منح الإذن.

الطفل : (أخيرًا قادر على اللعب).

يوضح هذا السيناريو البسيط أن عنصر التحكم يتمركز على الأصل. حرية الطفل مقيدة وتعتمد بدرجة كبيرة على سؤال الوالد. يمكن للطفل التحدث فقط عندما يُطلب منه التحدث ، ويمكنه التصرف فقط عند منح الإذن.

مع IoC:

أصبح لدى الطفل الآن القدرة على طرح الأسئلة ويمكن للوالد الرد بالإجابات والأذونات. يعني ببساطة التحكم المقلوب! يتمتع الطفل الآن بحرية طرح الأسئلة في أي وقت ، ورغم أنه لا يزال هناك تبعية مع الوالد فيما يتعلق بالأذونات ، فهو لا يعتمد على وسائل التحدث / طرح الأسئلة.

بطريقة تكنولوجية في التوضيح ، يشبه هذا إلى حد كبير تفاعل وحدة التحكم / shell / cmd مقابل واجهة المستخدم الرسومية. (وهو إجابة لمارك هاريسون أعلاه no. الجواب العلوي). في وحدة التحكم ، تعتمد على ما يتم طرحه / عرضه لك ولا يمكنك الانتقال إلى القوائم والميزات الأخرى دون الإجابة على السؤال أولاً ؛ بعد تدفق تسلسلي صارم. (برمجياً ، هذا يشبه حلقة الأسلوب / الوظيفة). ومع ذلك ، في واجهة المستخدم الرسومية ، يتم وضع القوائم والميزات ويمكن للمستخدم اختيار كل ما يحتاج إليه وبالتالي الحصول على مزيد من التحكم وأقل تقييدًا. (برمجيًا ، تحتوي القوائم على رد اتصال عند تحديده ويتم إجراء ما).


يتحدث البرمجة

IoC بعبارات سهلة: إنه استخدام Interface كوسيلة لشيء معين (مثل حقل أو معلمة) كحرف بدل يمكن استخدامه من قبل بعض الفئات. يسمح بإعادة استخدام التعليمات البرمجية.

على سبيل المثال، دعنا نقول أن لدينا فئتين: الكلب و القط . يشترك كلاهما في نفس الصفات / الحالات: العمر ، الحجم ، الوزن. لذلك بدلاً من إنشاء فئة خدمة تسمى DogService و CatService ، يمكنني إنشاء خدمة واحدة تسمى AnimalService تسمح باستخدام Dog and Cat فقط إذا كانا يستخدمان الواجهة IAnimal .

ومع ذلك ، تحدث بشكل عملي ، فقد بعض الوراء.

أ) معظم المطورين لا يعرفون كيفية استخدامها . على سبيل المثال ، يمكنني إنشاء فئة تسمى العميل ، ويمكنني إنشاء واجهة تسمى ICustomer تلقائيًا (باستخدام أدوات IDE) . لذلك ، ليس من النادر العثور على مجلد مليء بالفئات والواجهات ، بغض النظر عما إذا كان سيتم إعادة استخدام الواجهات أم لا. يطلق عليه مبيض. قد يجادل بعض الناس بأنه "قد يكون في المستقبل يمكننا استخدامه". : - |

ب) لديه بعض القيود. على سبيل المثال ، دعنا نتحدث عن حالة Dog and Cat وأريد إضافة خدمة جديدة (وظائف) للكلاب فقط. دعنا نقول أنني أريد حساب عدد الأيام التي أحتاج فيها لتدريب كلب ( trainDays()) ، لأنه لا فائدة من القط ، لا يمكن تدريب القطط (أنا أمزح).

ب .1) إذا أضفت trainDays()إلى خدمة AnimalService ، فإنها تعمل أيضًا مع القطط وهي غير صالحة على الإطلاق.

ب .2) يمكنني إضافة شرط trainDays()حيث يتم تقييم الفئة التي يتم استخدامها. لكنه سوف كسر IoC تماما.

ب 3) يمكنني إنشاء فئة جديدة من الخدمة تسمى DogService فقط للوظيفة الجديدة. ولكن ، سيزيد من إمكانية المحافظة على الكود لأنه سيكون لدينا فئتان من الخدمة (مع وظائف مماثلة) لـ Dog وهي سيئة.


يهدف IoC إلى قلب العلاقة بين الشفرة ورمز الجهة الخارجية (المكتبة / الإطار):

  • في تطور s / w العادي ، تكتب الطريقة الرئيسية () وتستدعي أساليب "المكتبة". أنت في السيطرة :)
  • في IoC ، يتحكم "الإطار" main () ويستدعي طرقك. في الإطار هو في السيطرة :(

تدور DI (حقن التبعية) حول كيفية تدفق التحكم في التطبيق. يحتوي تطبيق سطح المكتب التقليدي على تدفق تحكم من تطبيقك (الطريقة الرئيسية) إلى استدعاءات طريقة مكتبة أخرى ، ولكن مع قلب تدفق التحكم DI ، يتولى إطار العمل بدء تشغيل التطبيق الخاص بك ، وتهيئته واستدعاء الأساليب الخاصة بك كلما لزم الأمر.

في النهاية تربح دائمًا :)


انقلاب التحكم يدور حول نقل التحكم من المكتبة إلى العميل. من المنطقي أكثر عندما نتحدث عن عميل يقوم بضخ (تمرير) قيمة دالة (تعبير lambda) في وظيفة ذات ترتيب أعلى (وظيفة مكتبة) تتحكم في (تغير) سلوك وظيفة المكتبة. يمكن اعتبار عميل أو إطار عمل يقوم بحقن تبعيات المكتبة (التي تحمل السلوك) في المكتبات أيضًا IoC


باستخدام IoC ، فأنت لست جديدًا في تحديث كائناتك. حاوية IoC الخاصة بك ستفعل ذلك وتدير عمرها.

إنه يحل مشكلة الحاجة إلى تغيير كل مثيل من نوع كائن إلى آخر يدويًا.

يكون ذلك مناسبًا عندما يكون لديك وظيفة قد تتغير في المستقبل أو قد تختلف باختلاف البيئة أو التكوين المستخدم في.


يعجبني هذا التفسير: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

يبدأ بسيط ويظهر أمثلة على الكود أيضًا.

يحتاج المستهلك ، X ، إلى الفئة المستهلكة ، Y ، لإنجاز شيء ما. كل هذا جيد وطبيعي ، لكن هل يحتاج X حقًا إلى معرفة أنه يستخدم Y؟

ألا يكفي أن يعرف X أنه يستخدم شيئًا ما لديه سلوك Y وأساليبه وخصائصه وما إلى ذلك دون معرفة من الذي ينفذ السلوك فعليًا؟

من خلال استخراج تعريف تجريدي للسلوك المستخدم بواسطة X في Y ، كما هو موضح أدناه ، والسماح للمستهلك X باستخدام مثيل لذلك بدلاً من Y ، يمكنه الاستمرار في فعل ما يفعله دون الحاجة إلى معرفة تفاصيل حول Y.

في الرسم التوضيحي أعلاه ، يقوم Y بتنفيذ I و X يستخدم مثيل I. بينما من المحتمل جدًا أن X لا يزال يستخدم Y المثير للاهتمام هو أن X لا يعرف ذلك. إنها تعرف تمامًا أنها تستخدم شيئًا ما ينفِّذ I.

اقرأ المقال للحصول على مزيد من المعلومات ووصف الفوائد مثل:

  • X لا يعتمد على Y بعد الآن
  • أكثر مرونة ، يمكن تحديد التنفيذ في وقت التشغيل
  • عزل وحدة الكود ، اختبار أسهل

...


يعد Inversion of Control مبدأً عامًا ، في حين يدرك Dependency Injection هذا المبدأ كنمط تصميم لإنشاء رسم بياني للكائنات (أي أن التهيئة تتحكم في كيفية إحالة الكائنات لبعضها البعض ، بدلاً من الكائن نفسه الذي يتحكم في كيفية الحصول على مرجع إلى كائن آخر).

بالنظر إلى انعكاس التحكم كنمط تصميم ، نحتاج إلى النظر إلى ما نعكسه. Dependency Injection تحول التحكم في بناء رسم بياني للكائنات. إذا قيل لنا في مصطلح الشخص العادي ، فإن انعكاس السيطرة يعني تغيير في تدفق التحكم في البرنامج. على سبيل المثال. في التطبيق التقليدي المستقل ، لدينا الطريقة الرئيسية ، حيث يتم تمرير التحكم إلى مكتبات الطرف الثالث (في حالة استخدام وظيفة مكتبة الطرف الثالث) ، ولكن من خلال قلب التحكم بالتحكم يتم نقله من رمز مكتبة الطرف الثالث إلى رمزنا ، ونحن نأخذ خدمة مكتبة طرف ثالث. ولكن هناك جوانب أخرى تحتاج إلى قلبها في أحد البرامج - على سبيل المثال ، استدعاء الطرق والمواضيع لتنفيذ التعليمات البرمجية.

للمهتمين بمزيد من العمق على Inversion of Control ، تم نشر ورقة توضح صورة أكثر اكتمالا عن Inversion of Control كنموذج تصميم (OfficeFloor: استخدام أنماط المكاتب لتحسين تصميم البرامج http://doi.acm.org/10.1145/2739011.2739013 مع نسخة مجانية متاحة للتنزيل من http://www.officefloor.net/about.html ).

ما تم تحديده هو العلاقة التالية:

انقلاب التحكم (للطرق) = التبعية (الحالة) حقن + استمرارية حقن + حقن موضوع

ملخص العلاقة أعلاه لانقلاب التحكم متاح - http://dzone.com/articles/inversion-of-coupling-control





inversion-of-control