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
[swift]
class Api {
private let session: URLSession
init(session: URLSession) {
self.session = session
}
}
let urlSession = URLSession.shared
let api = Api(session: urlSession)
[/swift]
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
[swift]
class TableView: UITableViewController {
var customCell: CustomTableViewCell?
}
let tableView = TableView()
tableView.customCell = CustomTableViewCell()
[/swift]
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
[swift]
protocol TodoManager {
func deleteAllTodo(in todo: Todo)
}
[/swift]
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.