Pull to refresh

Comments 9

Как это работает с зависимостями зависимостей?
Т.е. если ImageProvider понадобится StorageProvider?

Написал небольшой gist как это можно решить https://gist.github.com/JiLiZART/d072b3cc9a8d181234f4f374bb5eda09, по сути нужно создавать отдельную структуру для ImageProvider.


По правильному, используя например Swinject, это выглядело бы так:


class AmazonImageProvider {
    init(container: Container) {
        self.storage = container.resolve(StorageProvider.self)!
    }
}

let container = Container()

container.register(StorageProvider.self) { _ in FileStorageProvider() }
container.register(ImageProvider.self) { c in
    AmazonImageProvider(container: c)
}
class AmazonImageProvider {
    init(container: Container) {
        self.storage = container.resolve(StorageProvider.self)!
    }
}



Попахивает сервис локатором

Ну, это он и есть, частный случай реализации IoC

Имхо, это антипаттерн, поскольку:
1. Привязывает бизнес-логику к инфраструктуре приложения (вы зависите от конкретного контейнера в худшем случае или от интерфейса в лучшем, но всеравно этому не место на уровне бизнесс-логики)
2. Вносите неявные зависимости между вашими сервисами. Чтобы однозначно понять от чего зависит ваш сервис недостаточно его контракта, нужно читать код
В таком случае мы не сможем разделить реализацию компонентов ImageProvider и ArticleProvider
Желательно добавить источник:
http://merowing.info/2017/04/using-protocol-compositon-for-dependency-injection/

т.е вот эта плашка вам ни о чем не говорит? image

Интересное решение. А как будет выглядеть вызов инициализации FooContainer, что вы ему передадите в качестве параметра?

Only those users with full accounts are able to leave comments. Log in, please.