Inversione del controllo
![Abbozzo](http://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Puzzle_stub.svg/45px-Puzzle_stub.svg.png)
![Niente fonti!](http://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Question_book-4.svg/45px-Question_book-4.svg.png)
In programmazione, soprattutto quella ad oggetti, l'inversione del controllo (in inglese inversion of control, abbreviato in IoC) è un pattern per cui un componente di livello applicativo riceve il controllo da un componente appartenente a una libreria riusabile. Può essere ulteriormente descritto come un design pattern nella quale un componente software è designato per ricevere le sue dipendenze da una fonte esterna , anziché crearsi le proprie. [1]Questo schema ribalta quello tradizionale della programmazione procedurale, dove il codice applicativo svolge i propri compiti richiamando (e quindi passando il controllo a) procedure di libreria[2][3][4].
Descrizione
L'obiettivo dell'inversione del controllo è lo stesso dell'Abstract factory: rendere le componenti software il più indipendenti possibile, affinché sia possibile modificarne una parte senza dover modificare le altre.
Le dipendenze tra i singoli componenti sono dichiarate in modo semplice. Per esempio una classe Automobile
che necessita di un oggetto di tipo Motore
, dichiarerà una variabile di istanza di tipo Motore
e un metodo per impostare a run-time il riferimento all'oggetto.
Le dipendenze possono quindi essere "iniettate" dall'esterno: non si segue il normale flusso di controllo dei linguaggi imperativi, in cui, nel momento del bisogno, si richiamano funzioni di classi o librerie esterne[5]. Gli oggetti non istanziano e richiamano gli oggetti dal quale il loro lavoro dipende, ma queste funzionalità vengono fornite da un ambiente esterno tramite dei contratti definiti da entrambe le entità.
Dependency injection
La Dependency injection è una delle tecniche con le quali si può attuare l'inversione del controllo. Essa prende il controllo su tutti gli aspetti di creazione degli oggetti e delle loro dipendenze. La libreria Java Spring usa molto diffusamente la Dependency Injection con il risultato, tra le altre cose, di eliminare dal codice applicativo ogni logica di inizializzazione. Normalmente, senza l'utilizzo di questa tecnica, se un oggetto necessita di accedere ad un particolare servizio, l'oggetto stesso si prende la responsabilità di gestirlo, o avendo un diretto riferimento al servizio, o individuandolo con un "Service Locator" che gli restituisce un riferimento ad una specifica implementazione del servizio. Con l'utilizzo della dependency injection, l'oggetto ha in sé solamente una proprietà che può ospitare un riferimento a quel servizio e, quando l'oggetto viene istanziato, un riferimento ad una implementazione di questo servizio gli viene iniettata dal framework esterno, senza che il programmatore che crea l'oggetto sappia nulla sul posizionamento del servizio o altri dettagli dello stesso.
Implementazioni ed esempi
Java
- il framework Spring
- Contexts & Dependecy Injection for Java che è parte di Java EE
- il framework Guice, su github.com.
- il Pico Container
.NET
- lo Unity Framework in .NET, su msdn.microsoft.com.
- il framework Castle Windsor
- DryIoc IoC Container per .NET, su github.com.
Note
- ^ Inversion of Control (IoC) Design principle ., su www.linkedin.com. URL consultato il 21 agosto 2024.
- ^ Inversion of Control Containers and the Dependency Injection pattern
- ^ Inversion of Control
- ^ IoC e DI (Inversion of Control e Dependency Injection)
- ^ (EN) Stefan Sobernig e Uwe Zdun, Inversion-of-Control Layer (PDF), in EuroPLoP '10: European Conference on Pattern Languages of Programs, New York, Association for Computing Machinery, 7 luglio 2010, ISBN 978-1-4503-0259-3. URL consultato il 28 giugno 2023.
V · D · M | |
---|---|
Creazionali | Abstract factory · Builder · Factory · Prototype · Singleton |
Strutturali | Adapter · Bridge · Composite · Container pattern · Decorator · Façade · Flyweight · Proxy |
Comportamentali | Chain-of-responsibility · Command · Interpreter · Iterator · Mediator · Memento · Observer · State · Strategy · Template method · Visitor |
Pattern di concorrenza | Active object · Balking · Binding properties · Double-checked locking · Event-based asynchronous · Guarded suspension · Join · Lock · Monitor · Proactor · Reactor · Read write lock · Scheduler · Thread pool · Thread-local storage |
Pattern architetturali | Front controller · Interceptor · MVC · n-tier · Specification · Publish–subscribe · Naked objects · Service locator · Active record · Identity map · Data Access Object · Data transfer object · ADR · Inversione del controllo |
Altri pattern | Blackboard · Business delegate · Composite entity · Dependency injection · Intercepting filter · Lazy loading · Mock object · Null object · Object pool · Servant · Twin · Type tunnel |
Libri | Design Patterns · Enterprise Integration Patterns |
Persone | Christopher Alexander · Erich Gamma · Ralph Johnson · John Vlissides · Grady Booch · Kent Beck · Ward Cunningham · Martin Fowler · Robert Martin · Jim Coplien · Douglas Schmidt · Linda Rising |
Comunità | The Hillside Group · The Portland Pattern Repository |
![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Computer_n_screen.svg/24px-Computer_n_screen.svg.png)