Dependency Injection

      Nessun commento su Dependency Injection

Salve a tutti cari amici di iProg, nell’ articolo di oggi vorrei introdurvi un desing pattern che io utilizzo molto ovvero il Dependency Injection. Per molti potrebbe sembrare un argomento ostico ma posso assicurarvi che non e’ cosi’ !!!

Questo design pattern ci consente di creare oggetti che dipendono da una classe al difuori di quest’ultima per poi poterli “iniettare”, in questo modo spostiamo la creazione e il legame degli oggetti dipendenti al di fuori della classe che dipende da esso.

Abbiamo sostanzialmente tre tipi di Dependency Injection:

  • Constructor Injection: la “dipendenza” viene iniettata all’interno del costruttore della classe
  • Property Injection:  l’iniettore fornisce la dipendenza attraverso una proprietà pubblica della classe
  • Method Injection: la dipendenza viene “iniettata” attraverso un metodo

Ma ora andiamo i vari esempi:

Constructor Injection

class Api {
    private let session: URLSession
    init(session: URLSession) {
        self.session = session
    }
}

let urlSession = URLSession.shared
let api = Api(session: urlSession)

Come potete notare dall’esempio soprastante e’ davvero molto semplice poter iniettare una dipendenza attraverso il costruttore, infatti e’ il metodo che preferisco.

Property Injection

class TableView: UITableViewController {
    var customCell: CustomTableViewCell?
}
let tableView = TableView()
tableView.customCell = CustomTableViewCell()

Come potete notare anche questo modo e’ molto semplice anche se non lo preferisco in quanto preferisco non avere proprieta’ pubbliche all’interno di una classe

Method Injection

protocol TodoManager {
    func deleteAllTodo(in todo: Todo)
}

Ora probabilmente vi starete chiedendo ok e’ tutto chiaro ma perche’ dovremmo mai usare questa metodologia?!
In realtaà il motivo è abbastanza semplice,  Iniettando le dipendenze di un oggetto, le responsabilità e i requisiti di una classe o di una struttura diventano più chiari e trasparenti, inoltre avremmo anche dei vantaggi nella testabilità in quanto in questo modo sarà possibile  sostituire le dipendenze di un oggetto con dei mock, il che rende più semplice e meno complicato isolare il comportamento e impostare i test unitari.

Un’altro grande vantaggio della D.I. e’ che può essere utilizzato per eliminare la necessità di utilizzare i singleton in un progetto, in quanto quest’ultimo dovrebbe essere utilizzato con “parsimonia” poche’ come ben sapete un oggetto singleton mantiene lo stato in un tutta l’applicazione e questo potrebbe produrre comportamenti indesiderati all’interno della nostra app.

Per concludere vorrei segnalarvi un feramework molto interessante Swinject che ci consente di gestire le dipendenze all’interno del nostro progetto in maniera molto semplice.