имхо – зло

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

Будут спагетти просто красивые

если правильные модули – то получается намного меньше спагетти

А если еще DI добавить и viper притащить, то проект по стоимости становится как самолет

А падает так же, как и обычный код

Печаль беда

А падает так же, как и обычный код

нет

у нас ручной di и всё ок

Я в принципе не против, раз находятся желающие платить за это все

И разработчикам не скучно

код который делает di очень простой и не требует много времени. Его иногда скучно писать, но зато ты прописываешь руками все зависимости явно

можно сначала попробовать начать с пары convinience – designated инициализаторов, convinience будет такой как раньше а designated будет принимать все зависимости.

что такое ДИ?

soliD

Dependency Injection

soliD

не совсем

https://www.equinox.co.nz/blog/dependency-inversion-dependency-injection-inversion-control-programming-interfaces

если ты конечно не имел в виду именно dependency inversion - тогда извиняюсь

а депенденси инжекшн - это создание дисигнитед инициализаторов и передача туда параметров?)

передача туда зависимостей в качестве параметров

да, DI можно сделать и так

а можно как делает objection

https://github.com/atomicobject/objection

что такое зависимости?)

ссылки на другие классы?)

ClassA *classA = [ClassA initWithClassB:self]

это передача зависимости и депенденси инжекшн?

ссылки на другие классы?)

Объекты, функции, числа. Напрмер если твой класс ImageFetcher загружает картинки, то он не должен внутри себя звать [NSURLSession sharedSession], а сессия должа быть передана в инициализатор.

а можно как делает objection

это вроде тайфуна?

Объекты, функции, числа. Напрмер если твой класс ImageFetcher загружает картинки, то он не должен внутри себя звать [NSURLSession sharedSession], а сессия должа быть передана в инициализатор.

аааа. А какая разница? В инициализаторе он же тоже переприсвоится какой-то переменной и будет так же вызываться? просто короче запись?

тестировать можно

тоесть это лишь для тестов делается?

аааа. А какая разница? В инициализаторе он же тоже переприсвоится какой-то переменной и будет так же вызываться? просто короче запись?

Разница в том, что (1) зависимость явная. (2) можно менее болезненно перейти на другой механизм фетчинга (повысить абстракцию)

(3) снаружи изменять поведение объекта, что дает гибкость

если твоему модулю (можешь считать для простоты "классу") A нужен для работы другой определённый класс B - это зависимость, причём явная. Например ты в инициализаторе прописал _session = [NSURLSession sharedSession]. В будущем ты не сможешь просто так перейти на какой-нибуть MySUPERSession без изменения своего класса A.

тоесть, переприсваивая его переменной - мы можем переписать геттер переменной и это будет повышением уровня абстракции?

угу

> мы можем переписать геттер переменной какой геттер?

DI говорит нам - передай свою сессию в инициализаторе, и не указывай в классе A её класс явно, и сможешь потом если что заменить её без проблем

например на сабкласс, или даже просто на что-то, что реализует тот же протокол

_session = [NSURLSession sharedSession] (session - это же пропертя?) - (NSURLSession)session { // чета тут делаем return // нужный результат }

для этого делается переприсваивание?

DI говорит нам - передай свою сессию в инициализаторе, и не указывай в классе A её класс явно, и сможешь потом если что заменить её без проблем

Погодите, но тогда наша MySUPERSession должна реализовывать все методы NSURLSession?

ну и плюс тестировать будет проще, опять же

MySUPERSession которая будет использоваться в классе A должна иметь только то, что надо для класса А

если ты конечно не имел в виду именно dependency inversion - тогда извиняюсь

я иногда путаю, так как почти не знаю другие механизмы реализации dependency inversion кроме как dependency injection.

если уж на то пошло, в классе A ты можешь вообще объявить её как (id session)

Погодите, но тогда наша MySUPERSession должна реализовывать все методы NSURLSession?

Для этого уже лучше использовать протоколы

Для этого уже лучше использовать протоколы

+1

и вообще дёргать через селекторы

если сильно хочется

но да, протоколы лучше

Я просто не понимаю

Вот я написал свой класс

Передал ему NSURLSession через инициализатор

И захотел поменять на MySUPERSession

Ну передам я MySUPERSession

Делая в вайпере проект понял что вайпер без ДИ ничего

Работать-то не будет. Внутри надо менять

В чем профит?

В чем профит?

Вы знаете что такое полиморфизм?

в классе A у тебя вообще нигде не упоминается NSURLSession

Вы знаете что такое полиморфизм?

Знаю

Вот создаете протокол

у тебя там везде упоминается лишь некий объект сессии, который должен реализовать протокол, который нужен для работы класса А

Там указывается все концертные методы

Вот создаете протокол

а. Ну речи об протоколе не шло изначально

Так-то понятно

потому ты можешь передать туда NSURLSession, MySUPERSession или всё что угодно что этот протокол реализует

Работать-то не будет. Внутри надо менять

(1) если MySUPERSession наследник NSURLSession – то всё будет работать. (2) ты можешь передать туда другую сессию, отличную от shared (например для инкогнито браузинга)

(1) если MySUPERSession наследник NSURLSession – то всё будет работать. (2) ты можешь передать туда другую сессию, отличную от shared (например для инкогнито браузинга)

Я имел в виду ситуацию, когда не наследник

Тогда надо под протокол

и даже протокол здесь необязателен - как я писал выше, ты можешь решать всё через id и селекторы

потому что Obj-C позволяет динамическую типизацию

это уже попахивает

питоном попахивает)

duck typing наше всё

но да, в продакшн коде лучше так не писать

duck typing наше всё

переодически ловим креши в проде с анрекогнайзд селекторами, так что лучше без этих радостей

тоесть вы всегда в коде в инициалзиаторе создаете @property (weak, nonatomic) id session - (instatype)init { ... _session = [NSUrlSession sharedSession] return self }

это явная зависимость, которая привязывает твой класс к конкретному классу NSUrlSession