Опросик такой, много кто юзает DI для iOS/macOS?

воскресенье не лучшее время для опросов

Речь о самом принципе или о фреймворках?

Опросик такой, много кто юзает DI для iOS/macOS?

Не видел ни одного примера гдебы без этих костылей было не обойтись.

Речь о самом принципе или о фреймворках?

Скорее про фреймворки

Кто-то делает DI без фреймворков?

Кто-то делает DI без фреймворков?

Да. Наследуешься да добавляешь пропертю.

Или речь про конфликт аббревиатур? DI - Dependency Injection, DI - Dependency Inversion :)

Да. Наследуешься да добавляешь пропертю.

А базовый класс типа абстрактный, без подставленных конкретных пропертей?

Кто-то делает DI без фреймворков?

мы

фреймворки для DI это какая-то дикая сложность на ровном месте

Dependency Injection это чудовищно простой концепт

А базовый класс типа абстрактный, без подставленных конкретных пропертей?

А что наследоваться можно только от абстрактного?

нахрена городить какие-то костыли вокруг?

нахрена городить какие-то костыли вокруг?

Попроси хоть один пример описать где необходим ДИ с фреймворками и поймешь масштабы бедствия)

В этом и проблема, что те несколько DI фреймворков что я видел, меня безумно печалили)))

В этом и проблема, что те несколько DI фреймворков что я видел, меня безумно печалили)))

Ты мне обьясни почему без них не обойтись?)

Обойтись, конечно. Хотелось инжектить удобнее :)

куда удобнее-то?

Всем привет. Я Андрей. Живу в Краснодарском крае. В данный момент работаю в Globus-ltd. В iOS разработке с 2013г. Из крупных проектов - мегафон_лк, теле2_тв, ну и по мелочи - bashreader, yandex_weather. Последнее время пишу с использованием либы https://github.com/GlobusLTD/components-ios (например, в ней кастомная замена TableView и CollectionView) Готов помочь тем, что в моих скромных силах) Пришел по линку Егора Толстого. #whois

Передай зависимость параметром

что может быть ещё удобнее?

что может быть ещё удобнее?

ну удобнее в 1 месте настраивать инжекты и не тянуть лапшу во все конструкторы

Ну на мой взгляд ты на ровном месте добавляешь когнитивной нагрузки на мозг читающего

без реальных профитов

я, кстати, не очень понимаю о какой лапше речь

Обойтись, конечно. Хотелось инжектить удобнее :)

а в каком случае это неудобно?

explicit is better than implicit

я только за explicit, когда у тебя проперти для инжектов помечены явно

дак ну сунь ты их в конструктор

дак ну сунь ты их в конструктор

для этого надо использовать новый модный фреймворк. под свифт конечноже

я только за explicit, когда у тебя проперти для инжектов помечены явно

проперти для инжектов? чем они от обычных пропертей отличаются?

В конструторы тогда тащить придется насковзь через весь код, этого как раз и хотелось бы избежать

ну удобнее в 1 месте настраивать инжекты и не тянуть лапшу во все конструкторы

Конструкторы не нужны. На модуль собрал Assembly класс, в аппделегате дергается аппдепенденси, он инициирует нужные модули и прокидывает интерфейсы между ними, если кому надо - скармливает им нужный набор ассемблей.

И фреймворки ненужны

В конструторы тогда тащить придется насковзь через весь код, этого как раз и хотелось бы избежать

то есть хочется избежать explicit :)

народу с Good Reads подвалило (:

Конструкторы не нужны. На модуль собрал Assembly класс, в аппделегате дергается аппдепенденси, он инициирует нужные модули и прокидывает интерфейсы между ними, если кому надо - скармливает им нужный набор ассемблей.

Вот это звучит немного пугающе, если чессно

то есть хочется избежать explicit :)

Ну explicit разный бывает :)

@property Alanytics<Injectable> *analytics; на мой взгляд вполне Explicit

@BeardedAndrew привет, мне тут как-то отдали вопросы собеседования в глобус, алгоритмов там не было :(

@property Alanytics<Injectable> *analytics; на мой взгляд вполне Explicit

а почему нельзя написать @property Alanytics *analytics;?

ну чтобы не тащить в init аргумент

или так: @property id<Alanytics><Injectable> analytics;

Всем привет из знойного Петербурга. Заходишь в группу первый раз, а тут уже битва за DI идет. Про необходимость использовать DI есть заметка в интернетах http://alejandromp.com/blog/2015/8/25/dependency-injection-without-frameworks/

ну чтобы не тащить в init аргумент

Тут такое дело: ответь на вопрос, честно, почему ты не хочешь тащить депенденси в конструктор? Обычно честный ответ звучит так "их очень много, конструктор будет гигантским"

а это значит, что у тебя класс в принципе неправильно написан

их не много их 2-5 шт обычно

ну чтобы не тащить в init аргумент

можно проперти все сделать отдельными, не тащить их в конструкторы, просто после установки вызвать метод [object setup]

настройки, аналитика, пара глобальных менеджеров

менеджер аудио например

> пара глобальных менеджеров ?

то что без DI было бы синглтонами

*пара глобальных менеджеров*

локейшн менеджер

то что без DI было бы синглтонами

хм, ну пусть будут синглтоном

ERROR: S client not available

синглтон потом при тестировании не подменить нормально

поэтому инжектится

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

да и синглтон можно же замокать

хм, ну пусть будут синглтоном

тогда какой смысл в DI?

тогда какой смысл в DI?

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

дак в том-то и поинт, чтобы не мокать синглтоны

не, в самом DI смысла много

loose coupling, всё вот это

как в паттерне

ну тут я ваще не согласен

а не как в спецфреймворках которые позволяют какието невероятные вещи делать

а вот фреймворки для DI это реально сложно и не нужно

то что без DI было бы синглтонами

Не синглтонами, а сервис локаторами ))))

Всем привет. Я Дмитрий. Нахожусь в Нижний Новгород/Москва Работаю на 1-ofd.ru, в ios с 2013 года. Совсем немного застал MRC. Пришел из web (AngularJS/ReactJS/NodeJS/GO/Groovy/Java) Опыт разработки банковских приложений, люблю CoreAnimation Могу помочь в CoreAnimation и в работе с Layout, знаю как работают и как надо применять content hugging and compression resistance Good Reads #whois

Не синглтонами, а сервис локаторами ))))

фасад синглтонов замутить еще))

фасад синглтонов замутить еще))

Ага ))

а вот фреймворки для DI это реально сложно и не нужно

Вот с этой проблемой я и пытаюсь бороться посл неск месяцев)

@BeardedAndrew привет, мне тут как-то отдали вопросы собеседования в глобус, алгоритмов там не было :(

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

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

Этот список, скорей всего до тебя отдали, видимо раньше не спрашивали.

>ios development >2018 >алгоритмы

>ios development >2018 >алгоритмы

надо надо. иначе потом выясняется что безье по точкам нарисовать не могут

надо надо. иначе потом выясняется что безье по точкам нарисовать не могут

Гуглится

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

зачем держать это в своей голове?

Гуглится

что гуглится? как векторы складывать?

третий алгоритмосрач за неделю