Да куда уж)

теперь исходники на php станут еще фееричнее

не, не станут, тайпхинтам уже лет 9 в пыхе

а кто что думает на счет такого кейса - есть сущность Wallet и есть 3rd пати ApiClient апишка которая достает Balance этого кошелька. Есть две идейки реализации, сделать сервис $balanceProvider->getBalanceForWallet(Wallet $wallet): Balance c зависимостью ApiClient или же прокидывать клиент как аргумент в сущность $wallet->balance(ApiClient $client): Balance

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

а почему провайдера не прокидывать?

Мне наоборот второй вариант выглядит менее логичным. Метод balance() у кошелька, который принимает APIClient ???

а почему провайдера не прокидывать?

при этом хорошо подумать над именем и интерфейсик закинуть в домен

а почему провайдера не прокидывать?

BalanceProvider в $wallet->balance(...) -?

BalanceProvider в $wallet->balance(...) -?

да

Мне наоборот второй вариант выглядит менее логичным. Метод balance() у кошелька, который принимает APIClient ???

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

Я потому и написал, что выглядит это не красиво

да

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

выделить из ApiClient частичные интерфейсы по операциям. Например, IPasswordChangingService.

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

Ага

Не про ООП, но не могу не поделиться https://www.theregister.co.uk/2017/08/25/vw_engineer_gets_3yrs_for_emissionbusting_sw/

С ООП у них может и всё хорошо было.

выделить из ApiClient частичные интерфейсы по операциям. Например, IPasswordChangingService.

Паттерн фасад, не?

хм, а причем здесь фасад?

хм, а причем здесь фасад?

потому что у меня 4 утра ия только что налил кофе (в кружку)

вот кому сейчас легко?!))

вот кому сейчас легко?!))

Мне. Только что проснулся.

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

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

ну кароч... я поразмыслил и тут уже нужно больше копать в сторону bounded context. У меня есть сущность Wallet и есть апишка, например ApiClient, и часть поведения Wallet берется оттуда, например чтобы получить баланс кошелька, мне нужно дернуть апишку

сперва думал так... $balanceProvider->getBalanceForWallet(Wallet $wallet)

тип сервис который будет отдавать баланс

но

Давай пофантазируем: Bounded Context -> Strategy -> Facade

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

$wallet->balance(); $wallet->addBonus($bonus); и тд

Не могу с долларами читать, страдаю

Богатый язык

Не могу с долларами читать, страдаю

ах...точно, немного не тот чат))

Wallet wallet = ... Balance bal = wallet.balance(); wallet.addBonus(new SomeBonus());

ну ты понял)

я специально встал пораньше, чтобы успеть,а тут телега :)

Давай пофантазируем: Bounded Context -> Strategy -> Facade

а вот тут я не совсем понял(

если заюзать стратегию то в ушерб инкапсуляции

но я особо не вижу как ее тут можно прикрутить...

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

только вот контекст это отдельный сервис

у меня есть еще идея...wallet делать как proxy

Ребят, привет. Перечитывал про IoС и DI и понял что я ничего не понимаю и совсем запутался. Может кто распутает мои мысли. В общем раньше я был такого мнения: Inversion of Control (инверсия управления) — это некий абстрактный принцип, набор рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент системы должен быть как можно более изолированным от других, не полагаясь в своей работе на детали конкретной реализации других компонентов. Dependency Injection (внедрение зависимостей) — это одна из реализаций этого принципа (помимо этого есть еще Factory Method, Service Locator). (Взято с хабра https://habrahabr.ru/post/131993/) Но затем я нашел такую статью http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html в которой говорится что: Инверсия управления (IoC) говорит об изменении потока исполнения, присуща фреймворкам и функциям обратного вызова и не имеет никакого отношения к управлению зависимостями. Передача зависимостей (DI) - это инструмент передачи классу его зависимости через конструктор, метод или свойство. И здесь я и запутался, на фразе что IoC не имеет никакого отношения к управлению зависимостями. Так всетаки как DI относится к IoC? или они не имеют отношения друг к другу? типа DI это инструмент предоставления зависимостей, а IoC это коллбеки, делегаты и т.д. в общем все что позволяет фреймворкам управлять нашим кодом?

Ребят, привет. Перечитывал про IoС и DI и понял что я ничего не понимаю и совсем запутался. Может кто распутает мои мысли. В общем раньше я был такого мнения: Inversion of Control (инверсия управления) — это некий абстрактный принцип, набор рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент системы должен быть как можно более изолированным от других, не полагаясь в своей работе на детали конкретной реализации других компонентов. Dependency Injection (внедрение зависимостей) — это одна из реализаций этого принципа (помимо этого есть еще Factory Method, Service Locator). (Взято с хабра https://habrahabr.ru/post/131993/) Но затем я нашел такую статью http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html в которой говорится что: Инверсия управления (IoC) говорит об изменении потока исполнения, присуща фреймворкам и функциям обратного вызова и не имеет никакого отношения к управлению зависимостями. Передача зависимостей (DI) - это инструмент передачи классу его зависимости через конструктор, метод или свойство. И здесь я и запутался, на фразе что IoC не имеет никакого отношения к управлению зависимостями. Так всетаки как DI относится к IoC? или они не имеют отношения друг к другу? типа DI это инструмент предоставления зависимостей, а IoC это коллбеки, делегаты и т.д. в общем все что позволяет фреймворкам управлять нашим кодом?

То что ты считал вначале как ioc называется dic

Dip

Dependency injection principe

Вторач трактовка ioc норм

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

Игорь ты случаем меня не знаешь??

То что ты считал вначале как ioc называется dic

Спасибо, вот это меня и смущало, что в львиной доле статей в говорится что ioc это принципы и перечисляют принципы из dip. Что мне сейчас и бросилось в глаза поэтому и полез копать)))

Игорь ты случаем меня не знаешь??

Кто же не знает Евгения Кувшинова )

Игорь ты случаем меня не знаешь??

По фото сложно сказать) но скорее всего нет

Кто же не знает Евгения Кувшинова )

Одногрупник с таким именем и фамилией

По фото сложно сказать) но скорее всего нет

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

Dependency injection principe

dependency INVERSION principle

Нихт фирштейн ?

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

Тогда что процентов что нет) я уже не учусь

Dependency INJECTION - это технология, Dependency INVERSION - это общий принцип

Я кстати начинал статью писать про все эти аббревиатуры даже план набросал но потом как всегда:(

Тогда что процентов что нет) я уже не учусь

ну мы в 2006 учились)

Dependency INJECTION - это технология, Dependency INVERSION - это общий принцип

И в чем заключается этот принцип?

лан забей)

И в чем заключается этот принцип?

A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions. https://en.wikipedia.org/wiki/Dependency_inversion_principle

гуглится это легко

A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions. https://en.wikipedia.org/wiki/Dependency_inversion_principle

Блин сори, я подумал про ioc

http://lmgtfy.com/?q=di+vs+dip

Dep INJECTION - это общее название механизма автоматического разрешения/внедрения зависимостей. e.g. Spring Framework in Java, Symfony DI and Pimple in PHP

ты что то скучный коняш к словам придераешься0

радуги, единороги, говнокод. тесты)

Dep INJECTION - это общее название механизма автоматического разрешения/внедрения зависимостей. e.g. Spring Framework in Java, Symfony DI and Pimple in PHP

Аа можно сказать что это подмножество inversion control для управления зависимостями?

Блин сори, я подумал про ioc

IoC чуть более общая штука, чем DIP. Например Event Loop в Javascript это тоже пример IoC

В общем получается что ioc и di это разные вещи и вторая статья как раз является верной

вторая входит в иос

как одна из возможных реализаций

В общем получается что ioc и di это разные вещи и вторая статья как раз является верной

DI плохая аббревиатура, она может означать как Inversion так и Injection

наряду с фактори например

В общем получается что ioc и di это разные вещи и вторая статья как раз является верной

да

как одна из возможных реализаций

Не реализаций, а просто как подмножество ioc именно по управлению зависимостями

Аа можно сказать что это подмножество inversion control для управления зависимостями?

Да. DIP это про то как применять IoC в ООП

ух предвкушаю срач

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

наряду с фактори например

Так с помощью фактори модно реализовывать di

я думаю это скорее будет реализация иос

а не ди

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

я бы понимал один из возможных способов сделать что то. иос - интерфейс, ди - имплементейшн

я бы понимал один из возможных способов сделать что то. иос - интерфейс, ди - имплементейшн

плохая аналогия