экзит прекратит весь скрипт

круто

экзит прекратит весь скрипт

спасибо

Чёрт. Я уже говорил, что было бы здорово сюда пригласить карма бота? чтобы считал благодарности

Чёрт. Я уже говорил, что было бы здорово сюда пригласить карма бота? чтобы считал благодарности

не здорово

главное не благодарности, а качественный и рабочий софт :)

Ребята, возникла ситуация, где необходимо данные объекта впихнуть в ассоциативный массив

Вот есть у меня к примеру класс Ticket с его полями (протект переменными): $id_ticket $sender_id $text

Стоит задача сделать элегантно быстро и надёжно в массив вида: $insert['id_ticket'] $insert['sender_id'] $insert['text']

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

Спасибо

$a = new A(); // Создали некий объект A $a = (array) $a; // Превратили объект в массив Только не говорите, что это было так просто?

главное не благодарности, а качественный и рабочий софт :)

почему все всегда закрывают свойства объектов?

Дописывая к ним отдельно сеттеры и геттеры

я вообще делаю только геттеры :)

когда обьект не меняется - все проблемы исчезают

единстенное где надо сеттер - это сущности.

но там тоже надо крайне аккуратно. чтобы непонятно кто не менял

Наверное, под сущностями вы имели ввиду DTO :)

нет. бизнес сущности

DTO должны создасться раз и все

надо новую - создай новую

Data Transfer Object?

Deployment Transaction Object

Ну с phpconf врядли ;-)

ok, я имел ввиду devconf

ok, я имел ввиду devconf

видео записаны. монтаж займет около месяца. не знаю почему так долго. а дальнейшая судьба неизвестна

то есть вот прям совсем не надо открывать свойства?

Даже если я тупо создаю объект на один раз

ну.. если почитаешь про immutable, то вероятно почерпнешь многое. реактовый главный хранитель данных - redux - хранит неменяемые данные. каждый раз создает новую копию.

ok, я имел ввиду devconf

https://devconf.ru/ru/members/pay

датывремя обьекты.. все переходят на иммутабельные

VO обьекты всегда делают иммутабельными.

Потому что если это адрес - страна, город, улица дом, то поменять в нем даже если дом - то это будет уже ДРУГОЙ адрес.

т.е. должен быть другим обьектом

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

Всегда - это кто? Они не обязаны быть иммутабельными, плюс по бизнес-логике данные могут меняться

человек поменял имя - значит можно менять...

Иммутабельность подразумевает, что мы не можем свойства менять

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

у меня немного... иначе

я создаю объект класса, он ещё с пустыми свойствами. Задача - заполнить свойства данными, а потом заюзать метод save что-то типо: $ticket = New Ticket(); $ticket->id_ticket = 2; $ticket->text = 'sadgdsgsdg'; $ticket->save();

ну Ticket то у тебя обьект логики.. там то можно. Но если прям уж чотко по DDD то создавать ты должен както так:

И всё, этот объект по сути можно удалять к чертям

Ticket::create(2, 'sfsfd');

потому что пока ты сделал только new и свойства не заполнил, у тебя какойто невалидный тикет..

Это значит, что я долеж описать метод create

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

public function create(id, text)

да. но если их много, то хзначит надо создавать некие валуе обьекты :)

static*

да, static упустил

Просто хочется сделать так, чтобы в случае изменения свойств вообще

логики

может быть в будущем надо будет убрать свойство text

а добавить два свойства oikakbolnojit и nadonyshke

То чтобы минимизировать изменение кода

впрочем, это всё равно только хуже станет, я уже понял

потому что пока ты сделал только new и свойства не заполнил, у тебя какойто невалидный тикет..

хм. А я методе save запихну проверку валидности

так то да. Но до save - этот обьект невалидный

То есть до этого момента всё равно никакого толка с объекта. А вот в момент save происходит запись в бд, вот там и можно сделать проверку валидности

он может попасть в другие функции.. и там юзаться...

есть такая теоретическая возможность

он может попасть в другие функции.. и там юзаться...

то есть из-за моих кривых рук?

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

я где-то что-то забыл и впихнул... неосторожно

этим кто-то по идее буду только я

раньше я просто с контроллера паковал всё в массив $insert['text'] = 'sdgdsg';

ERROR: S client not available

2 хороших статьи по теме: https://habrahabr.ru/post/268371/ https://habrahabr.ru/post/275599/

и процедурно вызывал Ticket::save($insert)

но процедурное использование класса - не зашквар ли это?

Рассудите, бывалые

ну смотри

Что такое "процедурное использование класса"?

Что такое "процедурное использование класса"?

ну процедурный способ

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

$ticketRepository->save($ticket);

Понял

сеттеры юзают для того, чтобы не просто установить значение, а ещё и проверить валидность данных

$ticket-id_ticket = 'lol ty lolka'

да. но это такой.. уже DDD стиль..

раньше я просто с контроллера паковал всё в массив $insert['text'] = 'sdgdsg';

Суть всяких DTO, Entity и прочих POCO как раз в том, чтобы не использовать такие массивы вроде insert. Ты везде в коде использвуешь дата-object, и только при передаче/сохранении/получении сериализуешь их во что-то еще

и всё, у меня там, где должен быть число, стоит текст

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

Содержать логику в сеттере нежелательно

У тебя может быть невалидный data-object

$object = DataObject::parse($data); $validator->validate($object);

да. эти правила для DTO.

но мы говорим об Entity

это немного другой мир

Я не про DTO, я про POCO в целом

Entity отличается от DTO только тем, что содержит идентификатор и может содержать логику

а я ещё и намутил тут воды

Но если следовать принципам SOLID, то логику в Entity стоит свести к необходимомму для работы с данными минимуму или вынести вообще

если например не установить свойство id_ticket

то метод save добавит в БД запись

а если указать, то обновит по иду

Ну ActiveRecord - удобный паттерн, когда у тебя мало кода, но нарушает принципы SOLID

Есть какая-нибудь дельная литература?

По тому, что вы перечислили