inversion-of-control - ما هو انقلاب التحكم؟





design-patterns (26)


Creating an object within class is called tight coupling, Spring removes this dependency by following a design pattern(DI/IOC). In which object of class in passed in constructor rather than creating in class. More over we give super class reference variable in constructor to define more general structure.

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

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



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

For quick understanding just read examples*

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

مع هذه الأشياء اقول التبعيات لها. والربيع يجعلها متاحة.
هذا يؤدي إلى تطوير التطبيقات المقترنة فضفاضة.

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

انعكاس حاوية التحكم (IoC):
هذا هو سمة شائعة من الأطر ، تدير اللجنة الأولمبية الدولية كائنات جافا
- من إصرار إلى تدمير من خلال BeanFactory.
- تسمى مكونات Java التي تم إنشاؤها بواسطة حاوية IoC beans ، وتقوم حاوية IoC بإدارة نطاق bons وأحداث دورة الحياة وأي ميزات 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) و Dependency Injection (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 .

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




To understanding the concept, Inversion of Control (IoC) or Dependency Inversion Principle (DIP) involves two activities: abstraction, and inversion. Dependency Injection (DI) is just one of the few of the inversion methods.

To read more about this you can read my blog Here

  1. ما هذا؟

It is a practice where you let the actual behavior come from outside of the boundary (Class in Object Oriented Programming). The boundary entity only knows the abstraction (eg interface, abstract class, delegate in Object Oriented Programming) of it.

  1. ماذا تحل من مشكلات؟

In term of programming, IoC try to solve monolithic code by making it modular, decoupling various parts of it, and make it unit-testable.

  1. متى يكون مناسبًا ومتى لا؟

It is appropriate most of the time, unless you have situation where you just want monolithic code (eg very simple program)




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

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

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




  1. So number 1 above . above

  2. Maintenance is the number one thing it solves for me. It guarantees I am using interfaces so that two classes are not intimate with each other.

In using a container like Castle Windsor, it solves maintenance issues even better. Being able to swap out a component that goes to a database for one that uses file based persistence without changing a line of code is awesome (configuration change, you're done).

And once you get into generics, it gets even better. Imagine having a message publisher that receives records and publishes messages. It doesn't care what it publishes, but it needs a mapper to take something from a record to a message.

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

I wrote it once, but now I can inject many types into this set of code if I publish different types of messages. I can also write mappers that take a record of the same type and map them to different messages. Using DI with Generics has given me the ability to write very little code to accomplish many tasks.

Oh yeah, there are testability concerns, but they are secondary to the benefits of IoC/DI.

I am definitely loving IoC/DI.

3. It becomes more appropriate the minute you have a medium sized project of somewhat more complexity. I would say it becomes appropriate the minute you start feeling pain.




يمكن العثور على شرح مكتوب بسيط جدًا هنا

http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

انها تقول

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




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

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

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




I like this explanation: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

It start simple and shows code examples as well.

The consumer, X, needs the consumed class, Y, to accomplish something. That's all good and natural, but does X really need to know that it uses Y?

Isn't it enough that X knows that it uses something that has the behavior, the methods, properties etc, of Y without knowing who actually implements the behavior?

By extracting an abstract definition of the behavior used by X in Y, illustrated as I below, and letting the consumer X use an instance of that instead of Y it can continue to do what it does without having to know the specifics about Y.

In the illustration above Y implements I and X uses an instance of I. While it's quite possible that X still uses Y what's interesting is that X doesn't know that. It just knows that it uses something that implements I.

Read article for further info and description of benefits such as:

  • X is not dependent on Y anymore
  • More flexible, implementation can be decided in runtime
  • Isolation of code unit, easier testing

...




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

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




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

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




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

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

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

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

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

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

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

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




البرمجة تحدث

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

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

ومع ذلك ، بشكل براغماتي ، فقد بعض إلى الوراء.

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

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

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

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

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




I found a very clear example here which explains how the 'control is inverted'.

Classic code (without Dependency injection)

Here is how a code not using DI will roughly work:

  • Application needs Foo (eg a controller), so:
  • Application creates Foo
  • Application calls Foo
    • Foo needs Bar (eg a service), so:
    • Foo creates Bar
    • Foo calls Bar
      • Bar needs Bim (a service, a repository, …), so:
      • Bar creates Bim
      • Bar does something

Using dependency injection

Here is how a code using DI will roughly work:

  • Application needs Foo, which needs Bar, which needs Bim, so:
  • Application creates Bim
  • Application creates Bar and gives it Bim
  • Application creates Foo and gives it Bar
  • Application calls Foo
    • Foo calls Bar
      • Bar does something

The control of the dependencies is inverted from one being called to the one calling.

What problems does it solve?

Dependency injection makes it easy to swap with the different implementation of the injected classes. While unit testing you can inject a dummy implementation, which makes the testing a lot easier.

Ex: Suppose your application stores the user uploaded file in the Google Drive, with DI your controller code may look like this:

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

When your requirements change say, instead of GoogleDrive you are asked to use the Dropbox. You only need to write a dropbox implementation for the StorageServiceInterface. You don't have make any changes in the controller as long as Dropbox implementation adheres to the StorageServiceInterface.

While testing you can create the mock for the StorageServiceInterface with the dummy implementation where all the methods return null(or any predefined value as per your testing requirement).

Instead if you had the controller class to construct the storage object with the new keyword like this:

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

When you want to change with the Dropbox implementation you have to replace all the lines where new GoogleDriveService object is constructed and use the DropboxService. Besides when testing the SomeController class the constructor always expects the GoogleDriveService class and the actual methods of this class are triggered.

When is it appropriate and when not? In my opinion you use DI when you think there are (or there can be) alternative implementations of a class.




IoC is also known as dependency injection (DI). It is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes, or a mechanism such as the Service Locator pattern

Spring-framework-referance.pfd page 27 (if counting all pdf document pages, it is in page 51)

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/pdf/spring-framework-reference.pdf




افترض أنك كائن. وانت تذهب الى مطعم:

بدون IoC : تسأل عن "apple" ، ويتم تقديمك دائمًا إلى Apple عندما تطلب المزيد.

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

لذلك ، من الواضح ، يفضل IoC عندما تحب الأصناف.




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

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

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




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

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

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

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

دعونا عكس السيطرة.

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

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

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

ترك جانبا مسألة النظافة ، آخر شكل من أشكال مراقبة عملية الشرب هو أكثر فعالية واقتصادية.

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

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

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

مثال:-

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. افصل ما يجب عليك القيام به من الجزء الذي يجب القيام به.
  2. تأكد من أن الجزء يعرف أقل قدر ممكن حول أي جزء ؛ والعكس بالعكس.

هناك العديد من التقنيات الممكنة لكل من هذه الخطوات على أساس التكنولوجيا / اللغة التي تستخدمها للتنفيذ.

-

جزء الانعكاس لعكس التحكم (IoC) هو الشيء المحير ؛ لأن الانعكاس هو المصطلح النسبي. أفضل طريقة لفهم IoC هي نسيان هذه الكلمة!

-

أمثلة

  • التعامل مع الحدث. معالجات الأحداث (ما يجب القيام به) - إثارة الأحداث (عند القيام بالجزء)
  • واجهات. العميل المكون (جزء ما عند القيام) - تنفيذ واجهة المكونات (ما يجب القيام به الجزء)
  • xUnit ثابت. إعداد و TearDown (ما يجب القيام به الجزء) - تستدعي إطارات xUnit إلى الإعداد في البداية و TearDown في النهاية (جزء عند القيام - إلى - فعل)
  • نمط تصميم أسلوب القالب. طريقة القالب عند القيام بعمل جزء - الجزء الفرعي البدائي تنفيذ ما يجب القيام به الجزء
  • أساليب حاوية DLL في COM. DllMain، DllCanUnload، etc (what-to-do part) - COM / OS (when-to-do part)



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

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

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




يتعلق IoC بمعالجة العلاقة بين رمزك ورمز الطرف الثالث (المكتبة / الإطار):

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

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

في النهاية تفوز دائما :)




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

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

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

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




Inversion of Control is a generic principle, while Dependency Injection realises this principle as a design pattern for object graph construction (ie configuration controls how the objects are referencing each other, rather than the object itself controlling how to get the reference to another object).

Looking at Inversion of Control as a design pattern, we need to look at what we are inverting. Dependency Injection inverts control of constructing a graph of objects. If told in layman's term, inversion of control implies change in flow of control in the program. على سبيل المثال. In traditional standalone app, we have main method, from where the control gets passed to other third party libraries(in case, we have used third party library's function), but through inversion of control control gets transferred from third party library code to our code, as we are taking the service of third party library. But there are other aspects that need to be inverted within a program - eg invocation of methods and threads to execute the code.

For those interested in more depth on Inversion of Control a paper has been published outlining a more complete picture of Inversion of Control as a design pattern (OfficeFloor: using office patterns to improve software design http://doi.acm.org/10.1145/2739011.2739013 with a free copy available to download from http://www.officefloor.net/mission.html )

What is identified is the following relationship:

Inversion of Control (for methods) = Dependency (state) Injection + Continuation Injection + Thread Injection




Using IoC you are not new'ing up your objects. Your IoC container will do that and manage the lifetime of them.

It solves the problem of having to manually change every instantiation of one type of object to another.

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




Inversion of control is about transferring control from library to the client. It makes more sense when we talk about a client that injects (passes) a function value (lambda expression) into a higher order function (library function) that controls (changes) the behavior of the library function. A client or framework that injects library dependencies (which carry behavior) into libraries may also be considered IoC








inversion-of-control design-patterns