Qual è il significato di "inversione" nel principio di progettazione di Dependency Inversion?

Da Wikipedia:

In traditional programming, the flow of the business logic is determined by objects that are statically assigned to one another. With inversion of control, the flow depends on the object graph that is instantiated by the assembler and is made possible by object interactions being defined through abstractions. The binding process is achieved through dependency injection, although some argue that the use of a service locator also provides inversion of control.

O in altre parole: nel tradizionale, i componenti di controllo non invertito di livello superiore dipendono da quelli di livello inferiore.

Questo è stato dimostrato come una limitazione, perché i componenti di alto livello perdono la possibilità di lavorare con più di un ambiente o componenti eccessivamente specifici di basso livello.

Con inversione del controllo , il paradigma precedente è invertito. I componenti di alto livello sono solo classi o interfacce astratte e di solito sono (e dovrebbero essere) dichiarati in un pacchetto o in un assembly che non ha alcuna dipendenza dal codice che li implementa, ed è l'implementazione del codice che dipende dal codice di livello superiore (< em> perché il codice di basso livello deve implementare un'interfaccia di alto livello o una classe astratta ).

Questa è la inversione !

Citazione di Bob Martin in suo articolo originale sull'argomento :

One might question why I use the word “inversion”. Frankly, it is because more traditional software development methods, such as Structured Analysis and Design, tend to create software structures in which high level modules depend upon low level modules, and in which abstractions depend upon details. Indeed one of the goals of these methods is to define the subprogram hierarchy that describes how the high level modules make calls to the low level modules. Figure 1 is a good example of such a hierarchy. Thus, the depen- dency structure of a well designed object oriented program is “inverted” with respect to the dependency structure that normally results from traditional procedural methods.

Quindi, come ho capito, avere il principio di inversione sul posto rende la politica di alto livello descritta in termini di astrazione piuttosto che componenti di utilità concreta. E dal punto di vista del modulo di alto livello la politica astratta rimane stabile. Qualsiasi cambiamento delle implementazioni di basso livello non costringe il modulo di alto livello a cambiare.

Il termine "inversione" distingue l'approccio dal modello tradizionale.

Metterò un esempio diretto dell'inversione del controllo.
Immagina di avere una classe televisiva:

class Television {
    private Button powerButton;

    public Television() {
        this->powerButton = new Button();
    }

    function turnOn() {
       this->powerButton->turnOnTV();
    }
} 

Come puoi vedere, la televisione è strettamente associata alla classe Button, un componente di basso livello. Ciò significa che la televisione dipende dalla classe del pulsante da attivare.

L'inversione del controllo determina che la televisione non deve dipende dalla classe Button. Cioè: " La televisione non deve istanziare una classe Button "

La soluzione sarebbe una cosa del genere:

class Television {
    private ISomethingThatTurnsOnTV thisTurnsOnTV;

    public Television(ISomethingThatTurnsOnTV somethingThatTurnsOnTV) {
        this->thisTurnsOnTV = somethingThatTurnsOnTV;
    }

    function turnOn() {
       this->thisTurnsOnTV->turnOnTV();
    }
} 

Ora la televisione non sa se è un pulsante, un telecomando o un gesto umano la cosa che sta accendendo il televisore. E il pulsante deve implementare l'interfaccia ISomethingThatTurnsOnTV, che è un componente di alto livello.

Quindi siamo passati da:

ad alto livello ----------------------- basso livello
La televisione ---- dipende da ---- > Pulsante

A:

lowLevel ------------------------- highLevel
Button ----- dipende da -------- > ISomethingThatTurnsOnTV

e la televisione non dipende più da Button: D

Il problema è che il cosiddetto "principio di inversione delle dipendenze" è mal chiamato e definito. Mentre la definizione è stata chiarita dall'autore in seguito, il nome è un termine improprio. Non ci sono dipendenze che vengono invertite quando viene applicato questo principio.

Tradizionalmente, le tue dipendenze sarebbero discese verso il basso nella tua applicazione.

Cioè, avresti una classe di alto livello A, che dipende da una classe di livello inferiore B.

Considera un'auto. Nella programmazione tradizionale, l'oggetto della tua auto dipende dal tuo oggetto volante, che dipende dai tuoi due oggetti ruota anteriore. Ciò significa che se le tue ruote cambiano, la tua classe di volante deve cambiare, e la tua classe di macchina potrebbe anche dover cambiare.

Car -> SteeringWheel -> Wheels

L'inversione delle dipendenze elimina queste dipendenze e aggiunge due nuove dipendenze:

Car -> ISteeringWheel
SteeringWheel implements ISteeringWheel
SteeringWheel -> IWheels
Wheels implements IWheels

Questo cambiamento significa che ora possiamo testare l'auto indipendentemente dallo SteeringWheel, lo SteeringWheel indipendentemente dalle ruote. Possiamo anche modificare l'implementazione di Wheels o SteeringWheel senza dover apportare modifiche a una delle classi parent.

Questo rende l'architettura molto più flessibile e ci aiuta a garantire che gli altri principi SOLID (in particolare l'SRP) non siano violati.

L'inversione non è un'inversione delle dipendenze (dopo tutto, le Ruote non dipendono da SteeringWheel ora) ma sta trasformando le dipendenze di 90 gradi in una nuova astrazione. L'inversione è probabilmente una scelta scadente di parole. Una scelta più descrittiva potrebbe essere la "Destra Angolata Destra". Ma non è così accattivante.