Кажись от сути вопроса ушли в сторону, вопрос был о

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


Для пояснения, может кто не знал, межклассовые отношения:
Композиция, зависимость, наследование(наследование, интерфейсы), агрегация, ассоциация - это силы связи, различаются по жесткости. Условно A is B, A uses B, A has B, A owns B

в моём понимании, композиция подразумевает, что класс-пользователь знаком с интерфейсом класса-утилиты. т.е. не только знает, что бывает такой класс, но и знает сигнатуру его методов и может их использовать. при чём эти утилиты следует задавать именно интерфейсами, чтобы не зависеть от конкретных реализаций. речь, например, о class User { protected ItnerfaceUtil $Util; }

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

Зависимость это агрегация? Просто обычно выбирают между композицией и агрегацией, зависимость в обеих ситуациях есть

Да тут полностью согласен, но есть еще детали, которые многие упускают я так понял. Слово зависимость в контексте межклассовых отношений имеет разные уровни/силу связей. Они определены в UML нотации диаграмма классов. Ассоциация, композиция, агрегация, наследование(два типа наследование и интерфейсы), зависимость.Вот последний пункт он определен типо как в методе класса A создается return new B(), вопрос был в том как оно реализовано кодом, это такой способ связи как я понял не хранящий в сотсоянии объекта А. Так как он исключетельно известен только в методе

Ммм, а можешь показать источник на которые ты ориентируешься? Ты ж понимаешь что это не категории, они пересекаются и т д.

Любой учебник по UML диаграмма классов, в поиске вбей UML диаграмма классов межклассовые отношения. Тут картинки не шлются) давай в личке продолжим

Любое прямое использование одного класса в другом является зависимостью одного от другого. Так что весьма странно слово "зависимость" рассматривать отдельно.

мне не интересно в личке

смотри. Вот у нас есть dependency: class A { public function doSomething() { return new \DateTime(); } public function somethingElse(User $user) { $user->doSomething(); } } то есть либо мы внутри ее создаем, либо она приходит извне. Но A не хранит референс а значит доступна наша зависимость только в течении вызова метода. Но жизненные циклы объектов не пересекаются. Ассоциация же подразумевает что у тебя объект хранит ссылку всегда class User { private Profile $profile }

Return new b это разве не композиция?🤔

если ты выплевываешь объект наружу то ты теряешь контроль за жизненным циклом. А значит это не композиция и не агрегация

А что это тогда за зависимость получается?)

зависимость это "мой класс знает про другой класс и он ему нужен". Не важно как.

Нет конечно, композицией оно станет тогда когда будет является состоянием к примеру объекта А через свойство, тоесть в жизненом цикле объекта. Тут Сергей все расписал, а у тебя еще вопрос возник))

Ну тут больше вопрос что это за зависимость) Которая не участвует в жизненном цикле, но в то же время является зависимостью)

Хороший вопрос, который у меня тоже появился, после разбора UML )

Ну смотрел мистера Сойера, он говорит об это как использование, тоесть самое слабое зацепление. Еще же такое встретичь в абстрактной фабрике)

Хотя...., B зависит от А в таком случаи, тоесть мы рассматриваем что источник(B) зависит о цели A, пока А не вызовет метод B не появится, условно это является зависимостью. А все остальное как и было сказано уже ассоциацией разных видов(агрегация, композиция) - зависимость с жизненным циклом.