Inversion of control

Martin Fowler site

• Martin Fowler InversionOfControl

One important characteristic of a framework is that the methods defined by the user to tailor the framework will 
often be called from within the framework itself, rather than from the user's application code. 
The framework often plays the role of the main program in coordinating and sequencing application activity. 
This inversion of control gives frameworks the power to serve as extensible skeletons. 
The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.
-- Ralph Johnson and Brian Foote

• Inversion of Control Containers and the Dependency Injection pattern

Miro Samek

• BOOK:Practical UML Statecharts in C/C++Event-Driven Programming for Embedded Systems
  • Safari books
    • In contrast, most event-driven applications are structured according to the Hollywood principle, which essentially means “Don't call us, we'll call you.” So, an event-driven application is not in control while waiting for an event; in fact, it's not even active. Only once the event arrives, the event-driven application is called to process the event and then it quickly relinquishes the control again. This arrangement allows an event-driven program to wait for many events in parallel, so the system remains responsive to all events it needs to handle.

Stackoverflow

• stackoverflow what-is-inversion-of-control
  • Design Pattern
  • Control gets inverted from Programmer to container
    • Browser to Server
    • Main loop to events handlers
    • Forground to interrupts
    • Local to remote Libraries
    • Program to user in Window-GUIs
    • Critical when doing test-driven development. Without IoC it can be difficult to test
    • Pushing out dependencies to the calling objects

dotnetslackers.com

• Inversion of Control and Dependency Injection with Castle Windsor Container - Part I
  • Inversion of Control (IoC) and Dependency Injection (DI) are two related practices in software development which are known to lead to higher testability and maintainability of software products
  • Hollywood Principle, which states: "don't call us, we'll call you"

At a glance, these patterns are said to be based on the Hollywood Principle, which states: "don't call us, we'll call you". 
With a canonical approach, you hard code the classes of the objects you want to instantiate in the source of your application, 
supply parameters to their constructors and manage their interactions. 
Each object knows at compile time which are the real classes of the objects they need to interact with, and they will call them directly. 
So, under this point of view, you and your objects are the ones calling Hollywood. 
 
To invert this approach, you need some support from a framework which makes your application smart enough to guess which objects to instantiate, 
how to instantiate them and, in general, how to control their behavior. 
Instead of working with concrete classes you'll work with abstractions like interfaces or abstract classes, 
letting your application decide which concrete classes to use and how to satisfy their dependencies on other components.

• How to switch from a canonical programming process to inversion of control.