))

Нет

в чём тогда разница?

На примере ручки?) =

На примере ручки?) =

можно и словами

можно и словами

Ну если кратко то на примере шариковой ручки))

Вот у тебя есть ручка внутри стержень

Ручка зависит от стержня

чет бред какой то пошел

Dependency Injection - внедрение зависимости, Dependency Inversion - внедрение зависимости через интерфейс

Вот и все отличия

Стержень создаётся отдельно и вставляется в ручку это ioc

di про то, как объекту передать\прокинуть зависимости dip про то, от чего объект должен зависеть, т.е. с чем у него есть связь

Общий принцип

Di это как стержень будет вставлять ся в ручку

А dip

Dependency Injection - внедрение зависимости, Dependency Inversion - внедрение зависимости через интерфейс

глупости

глупости

нет в общем то

Это когда твоя ручка зависит от какого-то абстрактного стержня

Те его интерфейса - физ размера

нет в общем то

dip вообще не говорит про механизм доставки зависимости, внедряются они или еще как-то там получаются

А не от конкретной реализации

dip вообще не говорит про механизм доставки зависимости, внедряются они или еще как-то там получаются

Но Dependency Inversion подразумевает Dependency Injection

поэтому я просто сократил все эти ненужные рассуждения

Но Dependency Inversion подразумевает Dependency Injection

нет

чет бред какой то пошел

И это не бред. А вопрос с реального собеса

На котором мне его задавали

нет

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

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

dep inversion вообще нигде не говорит про внедрение, ну вот совсем не про внедрение

ну да, перепутал

слова местами поменять

какие именно?)

одно про внедрение зависимости, второе про то, как эти зависимости создавать так, что бы уменьшить coupling

ой все

Вот последняя часть фразы это ioc

))

одно про внедрение зависимости, второе про то, как эти зависимости создавать так, что бы уменьшить coupling

в dip самое важное - разворот стрелочки, что вот зависел ты от базы данных(mysql например) и в мгновение ока перестал зависеть, потому что стрелочка развернулась, благодаря получению абстракции. Теперь ты просто говоришь, что тебе нужна база данных определенного вида с определенными характеристиками(например которая sql жевать умеет)

Спасибо за объяснение

как при этом твой объект ее получил роли ваще не играет

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

ну, это довольно простая штука в общем то

не рокет сайнс, да

хотя вот есть виды DI сложные, насколько я знаю

передача через конструктор или сеттер это самое легкое

там через фабрику как то есть вроде, точно не помню

хотя вот есть виды DI сложные, насколько я знаю

Есть ещё через проперти и метод, тот же сеттер

через рефлексию есть еще

там через фабрику как то есть вроде, точно не помню

Через фабрику это уже процесс сборки твоего объекта, а это уже не совсем di

да, я перепутал

через рефлексию самый сложный вариант DI

http://sergeyteplyakov.blogspot.com/2014/11/di-vs-dip-vs-ioc.html?m=1

Хороший бложик на эту тему

И чувак норм

Не егор256

Может не по теме. А кто что скажет про Closure и Closure Script? Пробовал может, игрался?

Только Clojure. Язик классний, если ти любитель лиспов :) А так от задач зависит - для каких задач нужен язик?

Если хочеться лиспа можно на scheme посмотреть - он простой..

Видос про di интересный, да

https://www.youtube.com/watch?v=0X1Ns2NRfks

есть еще такой челик

Вот такие штуки стоит переводить. Так как тема для новичков очень сложная порой

есть еще такой челик

мне чет его видосы не нравятся

хотя у него их дофига

из-за усов?

100% из-за усов

ну может еще из-за манеры говорить

ERROR: S client not available

Вот такие штуки стоит переводить. Так как тема для новичков очень сложная порой

сложна

ну может еще из-за манеры говорить

Небось изза подачи материала

Как шоу, а не по технарски)

никогда не понимал любителей "по технарски"

Ну скорее баланс нужен

Вот первый видос ок же

Ну скорее баланс нужен

https://www.youtube.com/watch?v=aqzvkwSiFTI

на вот на эту тему посмотри

Спс) завтра гляну. А то закис уже в больничке

\

https://www.youtube.com/watch?v=0X1Ns2NRfks

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

так, я наконец научился скачивать автосгенерированные субтитры с ютуба

воу, youtube-dl ?

или ты про это?

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

Я когда то тоже его смотрел, как то совсем не зашёл. Лучше смотреть того кто рисовал на бумажке.

MPJ очень хорош, имхо

Я рефакторил все эти определения Все эти термины взгляд под разными углам на одно и тоже (di, ioc, dip) Можно сказать что это всё описывает одно явление, такое как разделение зависимости классов посредством изменения зависимости класса от конкретных имплементаций на зависимость от интерфейсов. Интерфейсы должны быть хорошо продуманы и обладать минимумом деталей которые нужны для работы с сущностью которую они представляют. И те классы которые имплементируют эту сущность тоже должны следовать этому принципу т.е. тоже зависеть от интерфейсов, а не конкретных реализаций и так до самых мелких сущностей. Теперь если класс зависит от интерфейса, а не от конкретного инстанса он не может его создать сам и должен как то получить инстанс который реализует этот интерфейс, но для этого ему нужна чужая помощь и он перекладывает эту ответственность на других. Есть разные способы дать классу эту зависимость 1) сеттер 2) field injection 3) конструктор (правильный способ) 4) service locator https://upload.wikimedia.org/wikipedia/commons/4/42/Traditional_Layers_Pattern.png https://upload.wikimedia.org/wikipedia/commons/8/8d/DIPLayersPattern.png

ну вот я если вдруг решусь поинвестировать время в субтитры и перевод - то выберу скорее Code Walks

Я рефакторил все эти определения Все эти термины взгляд под разными углам на одно и тоже (di, ioc, dip) Можно сказать что это всё описывает одно явление, такое как разделение зависимости классов посредством изменения зависимости класса от конкретных имплементаций на зависимость от интерфейсов. Интерфейсы должны быть хорошо продуманы и обладать минимумом деталей которые нужны для работы с сущностью которую они представляют. И те классы которые имплементируют эту сущность тоже должны следовать этому принципу т.е. тоже зависеть от интерфейсов, а не конкретных реализаций и так до самых мелких сущностей. Теперь если класс зависит от интерфейса, а не от конкретного инстанса он не может его создать сам и должен как то получить инстанс который реализует этот интерфейс, но для этого ему нужна чужая помощь и он перекладывает эту ответственность на других. Есть разные способы дать классу эту зависимость 1) сеттер 2) field injection 3) конструктор (правильный способ) 4) service locator https://upload.wikimedia.org/wikipedia/commons/4/42/Traditional_Layers_Pattern.png https://upload.wikimedia.org/wikipedia/commons/8/8d/DIPLayersPattern.png

1, 2, 3 - Dependency Injection, 4 - Service Locator, а еще есть фабрики.

и все это - inversion of control

dependency inversion - штука намного шире

хотя и inversion of control штука оооочень широкая

а так все свозится к coupling и направлении зависимостей

Нужно, чтобы не нужно было инвестировать время в перевод. Берёшь и смотришь :)

Нужно, чтобы не нужно было инвестировать время в перевод. Берёшь и смотришь :)

не так я как бы и так их все посмотрел уже

Тогда вопросов нет

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

ну вот я если вдруг решусь поинвестировать время в субтитры и перевод - то выберу скорее Code Walks

держи в курсе, если чо)

Главное, чтобы они занимались хоть как-то английским, имхо. Сейчас 90% годной литературы именно на английском

хотя и inversion of control штука оооочень широкая

Приведи какие то конкретные примеры, более менее нормальное обьяснение с вики, откуда я взял эти картинки, всё остальное какой то cryptic shit

Главное, чтобы они занимались хоть как-то английским, имхо. Сейчас 90% годной литературы именно на английском

100%