код который делает 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

нет, в инициализатор как параметр сессия идет

С Id какое то извращение по мне)

в проде так не пишу - это моё питоновое прошлое нашёптывает

но у эппла в foundation так много где есть кстати

просто если в этом классе потом нужно заменить [NSUrlSession sharedSession] на что-то другое

я делаю контрл ф - финдр / реплейс

и в 1 кнопку все заменяю

но у эппла в foundation так много где есть кстати

вот, там забыл проверить на respondsToSel и всё

initWith имеется в виду

А туда уже NSURLSession

я делаю контрл ф - финдр / реплейс

Это выход, но типа не по канону)

и в 1 кнопку все заменяю

у тебя всё это на бэби кодинг похоже

я делаю контрл ф - финдр / реплейс

а теперь представь, что ты хочешь этот же код заиспользовать с 2мя разными классами сессий

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

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

так?) это теперь депенденси инжекшн?

всё ещё явная зависимость потому что в коде есть NSUrlSession класс

@property (weak, nonatomic) id<MySession> session - (instatype)initWithSession:(id<MySession>)session { ... _session = session; return self }

?

у тебя всё это на бэби кодинг похоже

угу) просто я в жизни не стыкался, когда это надо менять на что-то другое в процессе было бы.

@property (weak, nonatomic) id<MySession> session - (instatype)initWithSession:(id<MySession>)session { ... _session = session; return self }

+

И так практичнее

@property (weak, nonatomic) id<MySession> session - (instatype)initWithSession:(id<MySession>)session { ... _session = session; return self }

а если я через блоки делаю? и в классе MySession методы - loginUserWithParameters:(nsdict )parameters blockSuccess:(block)sucess failure:(block)failure

и в класе юзаю не [NSUrlSession sharedInstance]

а сразу нужный запрос делаю из моего класса?

блоки здесь это Inversion of Control

и он тож синглтон но вызывается [MySession sharedsessin]loginUser...