di - является, dip - нет

так что тут вопрос, может быть он про DI рассказывает?

p.s. мне кажется что рассказывать про DI в контексте IoC не выгодно

погоди но ведь DI частный случай реализации DIP

погоди но ведь DI частный случай реализации DIP

нет, просто без DI или IoC сложно добиться DIP

но ты можешь не использовать DIP и эксплуатировать DI

короч IoC - это изменение направления потока управления - don't call us, we call you. Пример - твой фреймворк вызывает контроллер а не контроллер дергает фреймворк и проверяет что ему надо отработать. Это нужно для реюза кода. DIP - это изменение направления зависимостей, то есть у нас есть DIP когда направление зависимостей не совпадает с направлением потока управления. Пример - PSR-3 логгеры всякие. Когда у тебя есть абстрактный модуль, и твой проект зависит от него. Но вызываем мы какой-нибудь monolog, который так же зависит от модуля psr-3 (что бы заимплементить интрефейс). ТАким образом направление потока управление у нас осталось тем же (приложение вызывает монолог) но направление зависимостей уже поменялось - мы зависем только от psr-3, так же как и монолог.

короч IoC - это изменение направления потока управления - don't call us, we call you. Пример - твой фреймворк вызывает контроллер а не контроллер дергает фреймворк и проверяет что ему надо отработать. Это нужно для реюза кода. DIP - это изменение направления зависимостей, то есть у нас есть DIP когда направление зависимостей не совпадает с направлением потока управления. Пример - PSR-3 логгеры всякие. Когда у тебя есть абстрактный модуль, и твой проект зависит от него. Но вызываем мы какой-нибудь monolog, который так же зависит от модуля psr-3 (что бы заимплементить интрефейс). ТАким образом направление потока управление у нас осталось тем же (приложение вызывает монолог) но направление зависимостей уже поменялось - мы зависем только от psr-3, так же как и монолог.

а dip с ioc это как будет?

а dip с ioc это как будет?

фреймворк твой сделает тебе твой класс который нуждался в зависимости и возможно еще и сам вызовет метод какой (или кого-то кто вызовет твой класс).

фреймворк твой сделает тебе твой класс который нуждался в зависимости и возможно еще и сам вызовет метод какой (или кого-то кто вызовет твой класс).

Ага, об этом и говорит Мартин Фаулер: How does DIP relate to IoC and DI? Consider what happens if you use DI to inject a low-abstraction dependency? For example, I could use DI to inject a JDBC connection into a Monopoly game so it could use a SQL statement to read the Monopoly board from DB2. While this is an example of DI, it is an example of injecting a (probably) problematic dependency as it exists at an abstraction level significantly lower than the domain of my problem. In the case of Monopoly, it was created several decades before SQL databases existed, so to couple it to a SQL database introduces an unnecessary, incidental dependency. A better thing to inject into Monopoly is a Board Repository. The interface of such a repository is appropriate to the domain of Monopoly rather than described in terms of a SQL connection. As IoC is about who initiates a calling sequence, a poorly designed callback interface might force low-level details (framework) details into code you write to plug into a framework. If that's the case, try to keep most of the business stuff out of the callback method and in a POJO instead.

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

ты можешь оценивать связь любых двух кусков кода

в том числе и модулей

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

"зацепление" в половине текстов это coheasion а у тебя там coupling

> как это можно проецировать на ооп? - у тебя есть 2 объекта, которые взаимодействуют. Один зависит от другого. - у тебя есть 3 объекта, которые взаимодействуют. И один должен вызвать в определенной последоватлеьности два других. - у тебя есть 2 объекта, один достает данные из другого, и что-то с ними делает

ну и т.д.

в целом главное понять что "объект" в ооп это тот же модуль. И могут быть группы объектов составляющих модуль... ну и т.д..

на разных уровнях это работает одинаково

я на русском на тему coupling/coheasion ничего не видал

ну мол из простого и легко усваиваемого. Даже на википедии уже вменяемее рассказывается

coupling разве не зацепление? О.о я ещё видел перевод coupling, как сопряжение

Переводить термины по обычному словарю — очень и очень плохая идея. Термины в строгих науках как математика, физика и пр. имеют строгое Определение (Definition). Так вот нужно искать не перевод термина, а перевод именно Определения. К сожалению у нас нет единого регулирующего органа как научные институты для математики и физики, где есть единственно верный перевод термина и определения.

есть много вариантов: coupling - связанность, зацепление, сопряжение cohesion - связность, сцепленность, зацепление...

мне нравится вариант - coupling = внешняя связанность а cohesion = внутренняя связанность

Предлагаю сменить название чата на "coupling vs cohesion" Чет как не зайду - только об этом и разговоров ?

coupling разве не зацепление? О.о я ещё видел перевод coupling, как сопряжение

можно еще просто не переводить термины и углубляться в их смысл а не в названия

короч IoC - это изменение направления потока управления - don't call us, we call you. Пример - твой фреймворк вызывает контроллер а не контроллер дергает фреймворк и проверяет что ему надо отработать. Это нужно для реюза кода. DIP - это изменение направления зависимостей, то есть у нас есть DIP когда направление зависимостей не совпадает с направлением потока управления. Пример - PSR-3 логгеры всякие. Когда у тебя есть абстрактный модуль, и твой проект зависит от него. Но вызываем мы какой-нибудь monolog, который так же зависит от модуля psr-3 (что бы заимплементить интрефейс). ТАким образом направление потока управление у нас осталось тем же (приложение вызывает монолог) но направление зависимостей уже поменялось - мы зависем только от psr-3, так же как и монолог.

Неправда. Приложение вызывает фреймворк и говорит ему: дай мне что у тебя там выполняет psr3. А фреймворк уже дёргает конкретный монолог. Потому что именно монолог был внедрен как psr3 внутрь приложения.

можно еще просто не переводить термины и углубляться в их смысл а не в названия

не всем понятны английские термины без перевода

Неправда. Приложение вызывает фреймворк и говорит ему: дай мне что у тебя там выполняет psr3. А фреймворк уже дёргает конкретный монолог. Потому что именно монолог был внедрен как psr3 внутрь приложения.

приложение не вызывает фреймворк. Фреймвор вызывает приложение и предоставляет ему зависимости.

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

иначе никакого IoC у нас тут нет

чисто для того, чтобы бросать в тех, кто задает вопросы

не всем понятны английские термины без перевода

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

тогда можно создать глоссарий терминов. и заппинить их

на гитхабке забросить

приложение не вызывает фреймворк. Фреймвор вызывает приложение и предоставляет ему зависимости.

Давай поговорим, что первично: приложение или фреймворк.

тогда можно создать глоссарий терминов. и заппинить их

https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

или будем просто ровняться на википедию)

Давай поговорим, что первично: приложение или фреймворк.

сначала был запрос...

или будем просто ровняться на википедию)

мы ж ее сами и отредактировать можем

Давай поговорим, что первично: приложение или фреймворк.

в каких терминах?) в терминах control flow первичным будет фреймворк.

в терминах зависимостей первичным должно быть приложение

отсюда и произрастают IoC и DIP

вот есть у тебя фреймворк - express.js

и приложение

function (req, res) { res.send('goodbye horses') }

в каких терминах?) в терминах control flow первичным будет фреймворк.

В терминах управления первична ОС, которая дёргает исполняемый файл приложения, я е фреймворка.

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

В терминах управления первична ОС, которая дёргает исполняемый файл приложения, я е фреймворка.

можно обобщить все до "инфраструктуры"

какой то бессполезный спор об очевидных вещах. а @f3ath вообще тупо тролит похоже

по сути IoC нам нужен что бы у нас был какой-то express.js который будет скрывать нюансы работы с http и превращать это просто в вызов нашего приложения. Ну и еще медиатор какой-то который будет дергать наш фреймворк. С операционками уже чуть интереснее. Твой фреймворк их вызывает, а не они твой фреймворк.

тебе тут не надо инвертировать поток управления

хотя опять же если ты подписался на событие - например что коннекшен пришел - то это уже можно трактовать как IoC

чет меня понесло

Я не троллю. Но я согласен, что для спора надо бы определиться что такое приложение. И окружение. И фреймворк.

ты читал вообще оригинальную публикацию где этот термин вводится?)

как бы в определении фреймворка один из пунктов это инверсия управления

http://www.laputan.org/drc/drc.html

именно

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

> This inversion of control gives frameworks the power to serve as extensible skeletons.

всем утра, что нового?

кстате, когда говорят о IoC и DI, то все забывают соотносить это с кодом и рантаймом

DI - это про код, IoC - это про рантайм

ERROR: S client not available

DI - это про код, IoC - это про рантайм

В каком смысле про рантайм?

В каком смысле про рантайм?

про то кто кого вызывает

а вызывать можно только в рантайме)

там связывание происходит (late binding)

Ммм, di не рантайм, фабрика рантайм?

di - это когда у тебя в классе нету создания сущностей, они все определены как зависимости

это про код

а IoC это когда мы этот код выполняем и вжух там подсоываются зависимости

(ну и не только, вжух и http запрос, вжух и аргументы консольного приложения)

IoC - это когда мы не общаемся с другими модулями, а общаемся с фреймворком, но это возможно только в рантайме (т.е. когда сушности инстанциированы)

IoC - это когда мы не общаемся с другими модулями, а общаемся с фреймворком, но это возможно только в рантайме (т.е. когда сушности инстанциированы)

Don't call us, we call you. Так о каком общении с фреймворком ты говоришь?

где ты такое определение IoC нашел? :)

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

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

где ты такое определение IoC нашел? :)

википедия > Inversion of control is sometimes facetiously referred to as the "Hollywood Principle: Don't call us, we'll call you".

оно не конфликтует с тем что ты сейчас описал, но мы напрямую фреймворк обычно не дергаем

я и не писал, что мы дергаем)

я написал "общаемся"

кстате, дергать тоже не будет нарушением ioc, если это элемент общения

ну там ивенты зафигачить

кстате, IoC довольно грусный принцип, и я бы его не продавал

именно как раз из-за того, что он реализается в основном через ивенты, а ивенты это жопа

кстате, IoC довольно грусный принцип, и я бы его не продавал

торговец принципами)

именно как раз из-за того, что он реализается в основном через ивенты, а ивенты это жопа

с чего это?

ну в системе ивентов тяжело консистентность ловить

че ж у тебя так с ивентов горит)

да IoC к ивентам относится также, как ивенты к консистентности

никак

че ж у тебя так с ивентов горит)

есть живые примеры ;)

тут еще конечно надо определиться, что мы под ивентами понимаем

да IoC к ивентам относится также, как ивенты к консистентности

ээээм... позволю себе не согласиться :)

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