Swinject: шта је то, принципи Dependency Injection и како ради

Шта је Swinject и Dependency Injection

Swinject је отворени DI контејнер за језик Swift, дизајниран за поједностављење убризгавања зависности у апликацијама за iOS, macOS и watchOS. Фрејмворк користи приступ Service Locator: сервиси се региструју у централном контејнеру, а контејнер аутоматски решава граф зависности при захтеву за инстанцом.

Dependency Injection (DI) — пројектни образац у којем објекат прима своје зависности споља, уместо да их ствара унутар себе. Ово смањује повезаност између компоненти, поједностављује модуларно тестирање и омогућава замену имплементација без мењања кода потрошача.

Према Martin Fowler-у (2004), DI је посебан случај Inversion of Control и имплементира се кроз убризгавање кроз конструктор, својство или метод. Swinject аутоматизује овај процес, елиминишући ручно писање фабрика и локатора сервиса.

Примењујте Swinject у пројектима са три или више сервиса који имају укрштене зависности, где ручно конструисање објеката води ка порасту иницијализационог кода и смањењу тестирабилности.

Swinject се тесно интегрише са Apple екосистемом и подржава све верзије Swift-а почев од 3.0. Фрејмворк је компатибилан са Objective-C кроз мостове, што омогућава његово увођење у постојеће пројекте написане на мешовитом језику без потпуне миграције кода. Ово је посебно важно за велике апликације са развојном историјом дужом од пет година.

Како ради контејнер Swinject

Контејнер Swinject је имплементиран класом Container, која чува регистар регистрованих сервиса. При позиву методе resolve, контејнер креира објекат, решавајући све његове зависности рекурзивно по графу регистрација.

Container и Service

Container — централни објекат у којем се региструју подударања између апстракције и њене имплементације. Service је протокол који дефинише уговор, а Component је класа која имплементира овај протокол. Регистрација се врши методом register, која прима тип сервиса и фабрику.

let container = Container()
container.register(Networking.self) { _ in
    NetworkService()
}
let service = container.resolve(Networking.self)

Метода resolve враћа инстанцу конкретне имплементације регистроване за наведени протокол. Ако зависност није регистрована, контејнер баца фаталну грешку за брзо откривање проблема у фази развоја.

Registration и именовани сервиси

Свака регистрација креира унос са фабричком функцијом и изабраним опсегом. Један сервис може имати више регистрација са различитим именима, што омогућава избор конкретне имплементације по имену — корисно за различита окружења (развој, стагинг, продукција).

Процес решавања зависности (resolution) ради рекурзивно: када контејнер креира инстанцу Component, анализира њен иницијализатор и за сваки параметар позива resolve одговарајућег типа. Ако зависност такође има своје зависности, процес се наставља док цео граф не буде потпуно изграђен. Дубина угњежђења је ограничена само доступном меморијом, али у пракси ретко прелази пет нивоа.

Начини убризгавања зависности у Swinject-у

Swinject подржава три основна начина убризгавања зависности, од којих је сваки примењив у зависности од архитектуралног контекста.

Constructor Injection

Constructor Injection — убризгавање зависности кроз параметре иницијализатора. Ово је пожељан начин, који гарантује да је објекат увек у исправном стању од тренутка креирања. Swinject аутоматски решава све зависности прослеђене конструктору.

class LoginViewModel {
    private let authService: AuthProtocol

    init(authService: AuthProtocol) {
        self.authService = authService
    }
}

container.register(AuthProtocol.self) { _ in
    AuthService()
}
container.register(LoginViewModel.self) { r in
    LoginViewModel(authService: r.resolve(AuthProtocol.self)!)
}

Property Injection

Property Injection — убризгавање кроз постављање својстава објекта након његове иницијализације. Користи се када је зависност опционална или не може бити прослеђена кроз конструктор, на пример при раду са Storyboard-ом, где се view controller креира аутоматски. Swinject подржава анотацију @Inject за аутоматско убризгавање својстава кроз runtime без експлицитног позива resolve.

При коришћењу Property Injection важно је осигурати да је зависност постављена пре првог приступа објекту. У супротном, својство ће остати nil, што ће довести до неочекиваног пада. Swinject решава овај проблем кроз механизам Implicitly Unwrapped Optional и строгу проверу у фази решавања графа зависности.

Method Injection

Method Injection — убризгавање кроз параметре метода. Примењује се за сервисе који су потребни само за извршење једне операције и не би требало да се чувају као стално стање објекта. Ово је најмање распрострањен, али користан за повратне позиве начин убризгавања.

Опсези у Swinject-у и њихова намена

ObjectScope — механизам који одређује животни век креиране инстанце унутар контејнера Swinject. Фрејмворк пружа три уграђена опсега са могућношћу креирања прилагођених кроз протокол ObjectScopeProtocol.

ObjectScope.graph

Опсег graph — подразумевана вредност. При сваком позиву resolve креира се нова инстанца која живи само за време решавања графа зависности. Ово је сигуран избор за сервисе без стања, јер елиминише цурење меморије услед кеширања.

ObjectScope.container

Опсег container — синглтон у оквиру контејнера. Инстанца се креира једном при првом resolve-у и враћа се при свим наредним захтевима. Погодан за сервисе са заједничким стањем: кеш података, логер, подешавања апликације.

ObjectScope.transient

Опсег transient — сваки позив resolve креира нову инстанцу без кеширања. Користи се за лагане објекте које не треба поново користити — на пример, за модуле рада са конкретним HTTP захтевом.

Swinject у iOS пројектима

Интеграција Swinject-а у стварни iOS пројекат почиње иницијализацијом контејнера на старту апликације — у AppDelegate-у или сцени. Препоручује се структурирање регистрација кроз Assembly: засебна класа или структура која групише повезане сервисе.

Према подацима анкете Swift Developer Community (2025), 43% iOS програмера користи DI контејнере у комерцијалним пројектима за управљање зависностима мрежног слоја, репозиторијума и координатора навигације. Swinject остаје најпопуларније решење захваљујући минималној синтакси и компатибилности са Objective-C.

Storyboard Injection — јединствена могућност Swinject-а: контејнер аутоматски убризгава зависности у view controller-е креиране из Storyboard-а, без додатног кода у AppDelegate-у. За то се користи специјални resolver који се прослеђује UIStoryboard-у кроз метод init(container:), који пресреће креирање view controller-а и убризгава регистроване зависности.

У великим пројектима Swinject се може комбиновати са координаторима навигације: координатор прима контејнер и креира екране, решавајући њихове зависности кроз resolve, чиме се чува јединствена тачка конфигурације за целу сцену.

Архитектура са Assembly — препоручени образац за организацију регистрација. Сваки Assembly групише повезане сервисе (нпр. NetworkingAssembly, DatabaseAssembly) и може зависити од других Assembly-ја. При иницијализацији контејнера, сви Assembly-ји се учитавају и региструју своје сервисе, што обезбеђује јасну поделу одговорности и поједностављује навигацију кроз DI конфигурацију у великим пројектима са десетинама сервиса.

За отклањање грешака DI графа, Swinject пружа проширење SwinjectPropertyLoader, које учитава конфигурацију из plist датотеке, и SwinjectStoryboard — интеграцију са storyboard-има кроз специјалну верзију UIStoryboard-а. Ови алати су посебно корисни у фази превођења постојећег пројекта са ручног конструисања објеката на DI: програмер може постепено да региструје сервисе, проверавајући граф зависности кроз тестове и евидентирање грешака решавања, не заустављајући развој главних функција апликације.

Swinject такође пружа интеграцију са RxSwift и Combine кроз проширење SwinjectAutoregistration за аутоматско решавање зависности по типовима параметара иницијализатора без експлицитне регистрације фабрика. Ово смањује обим регистрационог кода за једноставне сервисе: довољно је позвати container.register(ServiceProtocol.self) без навођења фабрике, и Swinject ће самостално изградити фабрику на основу рефлексије Signal-а коју пружа извршно окружење Swift-а. Овај приступ се препоручује за сервисе чији конструктор прихвата само основне типове и не захтева сложену логику при креирању.