A
точно хотите знать?))
Дмитрий
если не самопис то да
A
Битриксовый)
Дмитрий
ух, но все равно имеет смысл погуглить "php-di bitrix router"
A
такого точно нет в гугле)
сами роуты в битриксе очень молодые)
еще никто не успел своей волосатой рукой поковырять их)
A
ладно, понял, спасибо) буду смотреть в сторону php-di
Дмитрий
как-то я хотел подключить sysmfony DI к примеру на чистом пхп, очень долго мучался, а php-di завелся с полпинка
Дмитрий
такого точно нет в гугле)
сами роуты в битриксе очень молодые)
еще никто не успел своей волосатой рукой поковырять их)
на самом деле DI пофиг на роуты, роут срабатывает а дальше из контейнера вытягиваем контроллер и запускаем ему метод и вот тут инъекции в конструкторе отрезолвятся сами без лишней работы, а вот инъекцию в методе хз. не практикую
Юра
Мне кажется проще использовать симфони микроыоеймворк чес писать с нуля
Юра
А то получится тоже самое почти только самописная сборная солянка какая-то
Дмитрий
Мне кажется проще использовать симфони микроыоеймворк чес писать с нуля
смотря что за проект, нюансы важны
Иван
Обучение, 0 латенси, console application, etc
или я тебя не понял, или ты меня
консоль - это повод использовать симфу или наоборот?
Дмитрий
Наоборот
Иван
а что в симфе с консолью не так?
Иван
ну и обучение, по симфе материалы точно есть, а какие материалы по кастомной сборке?
Konstantin
сверху вреднейшие советы, советую от них держаться подальше
Дмитрий
Ну смотри, решил ты написал маленькую программу зачем тащить симфу если там даже работы с БД не будет
Дмитрий
ну и обучение, по симфе материалы точно есть, а какие материалы по кастомной сборке?
Нет мы друг друга не понимаем
Иван
Ну смотри, решил ты написал маленькую программу зачем тащить симфу если там даже работы с БД не будет
если один скрипт, то конечно быстрее то, что быстрее
но просто для R&D что симфу ты ставишь, что руками индекс пхп с автолоадом - разница меньше, чем пойти сделать кофе
A
кстати, а какие есть варианты реализации композиции (вариант ассоциации), с di ?
т.е. основная идея композиции, это то, что один объект будет владеть другим))
Иван
кстати, а какие есть варианты реализации композиции (вариант ассоциации), с di ?
т.е. основная идея композиции, это то, что один объект будет владеть другим))
ну так в di при создании сервиса в конструктор передаются зависимости и таки да, получается композиция
Дмитрий
если один скрипт, то конечно быстрее то, что быстрее
но просто для R&D что симфу ты ставишь, что руками индекс пхп с автолоадом - разница меньше, чем пойти сделать кофе
Ну дак я про один скрипт и говорил, без автолоадинга может даже
A
так это уже не композиция)
A
это агрегация, когда зависимость создаётся вне класса
Юра
Создай в конструкторе )
Иван
это агрегация, когда зависимость создаётся вне класса
это внедрение зависимости, когда зависимость вне класса
Дмитрий
Понавыдумывают умных слов, пиши код блеать )
Юра
Понавнедряли тут зависимости
Дмитрий
Пока мы тут обсуждаем высокие материи Васян на Битриксе уже 16 тасок закрыл 😂
Юра
Небось не делал ресерч и ретроспективу
Дмитрий
@zatrofeemranoutrom я не про тебя )
Иван
Пока мы тут обсуждаем высокие материи Васян на Битриксе уже 16 тасок закрыл 😂
С даунтаймами и постмортемами
A
Хочу понять одно:
когда нам нужна композиция (чтобы жизненным циклом зависимостей управлял клиентский класс).
вроде все понятно. создал в конструкторе зависимости и все гуд))
но с другой стороны, как тестить такой класс?
один из вариантов, которые приходят в голову, все-таки внедрять зависимости через конструктор, а в деструкторе из убивать.
но скорее всего, такой вариант не будет работать, т.к. сборщик мусора не будет убивать класс, если у него есть живые зависимости (ссылки на другие объекты), или будет?)
Nikolay
Хочу понять одно:
когда нам нужна композиция (чтобы жизненным циклом зависимостей управлял клиентский класс).
вроде все понятно. создал в конструкторе зависимости и все гуд))
но с другой стороны, как тестить такой класс?
один из вариантов, которые приходят в голову, все-таки внедрять зависимости через конструктор, а в деструкторе из убивать.
но скорее всего, такой вариант не будет работать, т.к. сборщик мусора не будет убивать класс, если у него есть живые зависимости (ссылки на другие объекты), или будет?)
В большинстве случаев лучше использовать агрегацию вместо композиции
Дмитрий
Хочу понять одно:
когда нам нужна композиция (чтобы жизненным циклом зависимостей управлял клиентский класс).
вроде все понятно. создал в конструкторе зависимости и все гуд))
но с другой стороны, как тестить такой класс?
один из вариантов, которые приходят в голову, все-таки внедрять зависимости через конструктор, а в деструкторе из убивать.
но скорее всего, такой вариант не будет работать, т.к. сборщик мусора не будет убивать класс, если у него есть живые зависимости (ссылки на другие объекты), или будет?)
А мы точно про пхп говорим? Что-то сильно заморочено для того кто постоянно умирает
Юра
Вообще не понимаю. Пишу себе и ниразу такие вопросы не возникали
Konstantin
А мы точно про пхп говорим? Что-то сильно заморочено для того кто постоянно умирает
++, будто про спринг. нету в пхп никакого лайфтайма
Юра
В пхп рефкаунт гц
Павел
Хочу понять одно:
когда нам нужна композиция (чтобы жизненным циклом зависимостей управлял клиентский класс).
вроде все понятно. создал в конструкторе зависимости и все гуд))
но с другой стороны, как тестить такой класс?
один из вариантов, которые приходят в голову, все-таки внедрять зависимости через конструктор, а в деструкторе из убивать.
но скорее всего, такой вариант не будет работать, т.к. сборщик мусора не будет убивать класс, если у него есть живые зависимости (ссылки на другие объекты), или будет?)
Композиция нужна там, где ее тестить отдельно не надо. Например всякие OneToMany, VO и прочее
Павел
Ну и не надо заморачиваться
Павел
Надо прокинуть и менять - конструтор. Часть класса? Внутри
Юра
Пишешь в конструкторе иф тест, зэн мок класс
A
тогда, получается мы не может архитектурно создать такой класс, который удовлетворял одновременно этим двум критериям:
1. тестируемый код, и внедрение зависимости.
2. жизненный зависимостей, зависит от жизненного цикла зависимого класса.
?)
Nikolay
A
композиция)
class A {
function construct() {
$this->b = new B();
}
}
если класс А убили. В - тоже умирает.
Nikolay
Потому что композиция это часть чего то, а агрегация это отдельная часть и может существовать без другой
A
если я создают объект машины, который использует объекты двигателя и т.д.
то после удаления объекта машины должны удалиться все объекты (зависимости) (мотор, коробка передач, и т.д.)
Павел
Павел
если я создают объект машины, который использует объекты двигателя и т.д.
то после удаления объекта машины должны удалиться все объекты (зависимости) (мотор, коробка передач, и т.д.)
Технически даже если передать через контруктор, то при удалении машины, если нет ссылок на объект двигателя - все подчистится.
Павел
Короче какое то словоблудие бессмысленное и беспощадное)
Nikolay
Nikolay
Какие цели преследуются
A
Цель одна:
Нужен объект A, для работы которого нужны другие объекты - Б и В.
Нужно сделать так, чтобы при удалении объекта A, удалились объекты Б и В, т.к. они самостоятельно не имеют смысла.
Если создать объект Б и В внутри конструктора А, то это решит задачу.
Но из-за того, что создание объектов зашили внутри конструктора, появились две другие проблемы:
1. Сложно тестировать объект Б. Не знаю, как подменять Б и В.
2. Нарушение принципа DIP. Нет возможности подменять подмены Б, на что-то другое, например на его подтип.
Konstantin
у кого-то слишком много свободного времени и некоторая перловка в голове 🙂
A
Утечка памяти, уже столкнулись.
Konstantin
не мешайте человеку упражняться в слабоумии
A
У нас консюмер на пхп крутится))
Konstantin
утечка памяти абсолютно не зависит от ДИ, божечки
Konstantin
у вас течет сервис, сделайте так, чтобы он не тек. не надо создавать на каждый "запрос" новый инстанс сервиса, а потом героически воевать с гц
Konstantin
просто запустите все сервисы при старте и обеспечьте отсутствие утечек в своем коде, вы занимаетесь черт знает чем, вместо решения реальной проблемы
Konstantin
делаете стейтлесс-приложение из стейтфул, да которое еще и течет
Павел
у вас течет сервис, сделайте так, чтобы он не тек. не надо создавать на каждый "запрос" новый инстанс сервиса, а потом героически воевать с гц
Передоздавание сервиса, как то вроде не влечет к утечке
Юра
У тебя и так зависимость создаётся в контейнере и сразу передается в сервис. Кроме него никто больше от нее не зависит
A
утечка памяти абсолютно не зависит от ДИ, божечки
напрямую нет.
косвенно зависит.
если у вас постоянно создается объект А (и его зависимости Б и В), а удаляете вы только А. То в конечном итоге у вас будет миллион объектов Б и В
Юра
Какая разница где ты её создал
Konstantin
Передоздавание сервиса, как то вроде не влечет к утечке
оно ведет к потреблению других ресурсов и задержкам, это глупость - сделать демон, который делает реинит на каждое событие, разгребайте кроном, если не в состоянии
Павел
напрямую нет.
косвенно зависит.
если у вас постоянно создается объект А (и его зависимости Б и В), а удаляете вы только А. То в конечном итоге у вас будет миллион объектов Б и В
Если на них нет ссылок, или других живущих объектов - они потрутся
Павел
Иван
Юра
Сделай просто зависимость shared false
Юра
А то она будет одна на всех
Павел
Память просто так не "течет". Сборщик мусора работает норм. Главное чтобы нигде что-то не собиралось
Konstantin
Да, но не к утечкам
к утечкам ведет исключительно жопоручие и неправильный подход к задаче
Konstantin
решать надо именно эту проблему, а не пытаться сообразить кривой воркэраунд вокруг