Народ, это нормальная практика передавать $this в конструктор другого класа?

public function __construct($item) { $something = new BaseItem($item,$this); }

Для какой нибудь стратегии, да. Обращение к контексту

Народ, это нормальная практика передавать $this в конструктор другого класа?

и да и нет. Да потому что "ну а че нет", и нет если у тебя образуется циклическая ссылка. Последнее намекает что что-то пошло не так но увы и ах иногда надо

есть еще варианты доступа к вызывающему объекту

есть еще варианты доступа к вызывающему объекту

это и есть циклическая зависимость между двумя хреновинами. Это не есть хорошо с точки зрения декомпозиции, но (привет, доктрина) иногда ты ограничен возможностями библиотек

я иногда встречал такое: public function __construct($item) { $something = new BaseItem($item,[$this, 'methodName']); } или такое: public function __construct($item) { $something = new BaseItem($item, function($param) { return $this->methodName($param); }); }

это и есть циклическая зависимость между двумя хреновинами. Это не есть хорошо с точки зрения декомпозиции, но (привет, доктрина) иногда ты ограничен возможностями библиотек

Чем это чревато?

я иногда встречал такое: public function __construct($item) { $something = new BaseItem($item,[$this, 'methodName']); } или такое: public function __construct($item) { $something = new BaseItem($item, function($param) { return $this->methodName($param); }); }

тут нет передачи самого $this, это передача функции которая как раз таки разрывает эту самую циклическую зависимость.

Чем это чревато?

тем что у тебя как бы модуля два.... но как бы он один)

а дальше вопрос где ты границы провел между модулями. Это могут быть маленькие штуки а могут быть весьма жирные)

думаю в моем случае ничего страшного не произойдет)

сильная связность крч

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

думаю в моем случае ничего страшного не произойдет)

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

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

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

в дочерних нодах*

но с какого перепуга дети меняют родителя?

ну и опять же - структуры данных, типа двусторонних списков это отдельная история

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

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

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

кто знает о том какие у ряда свойства?

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

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

ну это не очень похоже на ооп но да можно и так) но тогда у тебя будет кто-то сверху кто вообще все знает

что хуже для связанности)

кто знает о том какие у ряда свойства?

ну сам ряд и все его дети :D

ну это не очень похоже на ооп но да можно и так) но тогда у тебя будет кто-то сверху кто вообще все знает

ну этим "кто-то сверху" может выступать и сам ряд, ну или сервис, которому это всё нужно в итоге

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

ты сапера пишешь? приведи пример свойств

притом можно по цепочке передавать ответственность: колонна знает о предметах, ряд о колоннах

Я пишу сетку для верстки)

Я пишу сетку для верстки)

ммм.... опиши еще раз суть задачи)

ООП головного мозга?

типа эмулируешь flexbox?)

или css-grid?

ООП головного мозга?

процедурщина головного мозга?

Я пишу сетку для верстки)

ну просто реально заинтриговал)

задача такая Есть в определенном ряду, в определенной колонне изображение, по умолчанию ряд по ширине контейнера(1600px) но если у изображения есть свойство типа $this->width = 'full' то и ряд тоже должен стать full

примерно так

казалось бы что тут нельзя сделать через css))

нельзя)

нужно изначально определить для ряда класс

нужно изначально определить для ряда класс

да нет же

обычный ли он или 100%

не надо просто разделять на ряды)

верстка это отдельная история, это же все же чатик про php)

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

вопрос по front я уже задавал в чате фронтендеров)

class Row { public function isFullWidth() { foreach ($this->cols as $col) { if($col->isFullWidth()) { return true; } } return false; } } class Col { public function isFullWidth() { foreach ($this->items as $item) { if($item->isFullWidth()) { return true; } } return false; } }

верстка это отдельная история, это же все же чатик про php)

ладно, твори что хочешь....

class Row { public function isFullWidth() { foreach ($this->cols as $col) { if($col->isFullWidth()) { return true; } } return false; } } class Col { public function isFullWidth() { foreach ($this->items as $item) { if($item->isFullWidth()) { return true; } } return false; } }

да, типа такого

да, типа такого

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

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

ну думай как развернуть направление зависимостей)

а со ссылкой на родителя будет только class Text { public function isFullWidth() { if($this->width == 'full'){ $this->row = 'full'; } } }

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

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

Субъективное мнение?

объективное

вместо isFullWidth ты можешь спросить конкретное свойство из детей и там например сумму свойст

ну, там, инкапсуляция, все дела...

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

вместо isFullWidth ты можешь спросить конкретное свойство из детей и там например сумму свойст

я не могу знать что у меня за дети и какие свойства у них есть

я не могу знать что у меня за дети и какие свойства у них есть

ну короч если тебе сделать и выкинуть - делай как хочешь) если надо гибко - надо думать)

я не могу знать что у меня за дети и какие свойства у них есть

тебе и не надо

но ты можешь знать какие свойства нужны от детей строке)

и их требовать в интерфейсе

В общем дети крайне сильно зависимы от родителя и не могут существовать без родителя как отдельная сущность)

ERROR: S client not available

тогда это больные дети, либо еще недоразвиты)

В общем дети крайне сильно зависимы от родителя и не могут существовать без родителя как отдельная сущность)

не могут существовать -> но знать о них не обязаны

а потом с развитием придется придумывать как же их выселить)

короч похеру, мне лень объяснять что есть масса вариантов разделить нормально эту логику

Мда)

судя по картинке - это проект одноразовый

так что пофигу

Ну как одноразовый)

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

это для создания динамической сетки

ну я даже в одноразовых проектах стараюсь)

он будет использоваться каждый день)

много раз)

он будет использоваться каждый день)

под одноразовым подразумевается "написано однажды, не дорабатывается никогда"

он будет использоваться каждый день)

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

эдакий Append Only код

под одноразовым подразумевается "написано однажды, не дорабатывается никогда"

ну он достаточно универсален, какой смысл его менять :D

ну он достаточно универсален, какой смысл его менять :D

ну так удачи

повторюсь - мы полностью задачу не знаем, может быть твой вариант наиболее логичен

(хотя скорее всего нет))

ну он достаточно универсален, какой смысл его менять :D

1) баги 2) новые требования, фичи

ну он достаточно универсален, какой смысл его менять :D

новые свойства, новое поведение

повторюсь - мы полностью задачу не знаем, может быть твой вариант наиболее логичен

Хочешь скину в личку более подробный пример? с кодом?)

Хочешь скину в личку более подробный пример? с кодом?)

не особо

пример с кодом тут и не поможет: если суть задачи — написать, запустить и забыть, то можно хоть процедурно в одном PHP-файле всё написать, а если нужно поддерживать, то надо будет подумать о том, насколько больно будет это делать

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

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

всеравно будет гореть

всеравно будет гореть

разница в интенсивности горения: может просто подгорать, а может сжечь уже десятое кресло)

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

а в некоторых случаях может начаться ректальная реактивная тяга

ну иногда бывает, когда прилетает откуда не ждали)

привет. Как бы вы зашили в коде к примеру идентификаторы пола? У нас есть цифровое представление - (0,1,2,3) и текстовое (male, female, trans... - оно как слаг в фильтре) ?