SB
Да это понятно, выбор не большой, между объектом и объектом))
ну вообще DTO это структура а не объект. Просто в некоторых языках нет структур вот люди и извращаются
Size: a a a
2021 February 03
ЕЧ
Да, в php нету)
a
Смысл в том, что с одной стороны есть какие-то особенности, из-за которых нет смысла называть этот объект ДТО или Модель, с другой стороны хочется дать имя, которое сориентировало бы того, кто потом будет работать с этим кодом, чтобы человек мог загуглить. Поскольку все эти концепты конвенциональны по своей природе, то вот спросил, может есть что-то более подходящее, но что я просто не знаю
я признаться честно подумал, что ты пародируешь мой вопрос, который тоже на тему фабрики которая не совсем фабрика
a
а может так и есть )
MG
Смысл в том, что с одной стороны есть какие-то особенности, из-за которых нет смысла называть этот объект ДТО или Модель, с другой стороны хочется дать имя, которое сориентировало бы того, кто потом будет работать с этим кодом, чтобы человек мог загуглить. Поскольку все эти концепты конвенциональны по своей природе, то вот спросил, может есть что-то более подходящее, но что я просто не знаю
Имя должно соотносится с бизнес-логикой. Ну и вряд-ли человек будет гуглить какие-то именования пока будет читать ваш код. Назовите попроще
АГ
если для класса трудно придумать название - значит класс неправильный, надо его разделить
SP
рич модель
хватит может уже? Богатые модели, бедные...
SP
если для класса трудно придумать название - значит класс неправильный, надо его разделить
или словарный запас увеличивать
AZ
Смысл в том, что с одной стороны есть какие-то особенности, из-за которых нет смысла называть этот объект ДТО или Модель, с другой стороны хочется дать имя, которое сориентировало бы того, кто потом будет работать с этим кодом, чтобы человек мог загуглить. Поскольку все эти концепты конвенциональны по своей природе, то вот спросил, может есть что-то более подходящее, но что я просто не знаю
ValueObject, если это не сущность
Называть так класс конечно не стоит, мб неймспейсом показать
Называть так класс конечно не стоит, мб неймспейсом показать
ЕЧ
Это объект, который содержит первичные данные после проверки токена во внешней системе. Нужен он в единственном экземпляре в одном лишь месте от мидлвары до мидлвары. Но в нём есть свойства в отношении многие ко многим, в мидлваре требуется проверить наличие нужных свойств и в случае успеха разделить коллекции уже отдельными свойствами для модели пользователя.
Я из любви к совершенству спросил, так сказать. Сделать как-нибудь-то я всегда успею. А поскольку все имена конвенциональны, то их нельзя вывести как-то логически, они результат прозрачности коммуникации и осведомлённости о её состоянии. Можно назвать по-своему и тебе может казаться, что ты офигеть как очевидно выразился, но другой человек придёт и будет твой ребус разгадывать)) Поэтому я спросил, вдруг есть, что предложить. Потому что подобные ситуации часто возникают, кругом объект на объекте, но хочется отделить один объект от другого по часто фигурирующим признакам.
Я из любви к совершенству спросил, так сказать. Сделать как-нибудь-то я всегда успею. А поскольку все имена конвенциональны, то их нельзя вывести как-то логически, они результат прозрачности коммуникации и осведомлённости о её состоянии. Можно назвать по-своему и тебе может казаться, что ты офигеть как очевидно выразился, но другой человек придёт и будет твой ребус разгадывать)) Поэтому я спросил, вдруг есть, что предложить. Потому что подобные ситуации часто возникают, кругом объект на объекте, но хочется отделить один объект от другого по часто фигурирующим признакам.
MG
Как по мне, в вашей любви к совершенству вам нужно помнить о разумных пределах. И, возможно, не заниматся овернеймингом в пользу утопичной понятности будущему поколению, которое будет работать с этим кодом. Ну и не забывайте о возможности поработать над документацией и граммотно описать эту часть системы, если уж вы так всё вылизиваете. Лично я бы сказал спасибо за хорошую доку, а не за крутой нейминг
MG
“объект, который содержит первичные данные после проверки токена во внешней системе…”
Вот возьмите этот абзац и запишите для “другого” человека просто словами. Хоть в комментарии, хоть в доке. Это будет куда более полезно, чем идеальное имя класса полученное усилиями 10 людей из телеграм-чата по архитектуре
Вот возьмите этот абзац и запишите для “другого” человека просто словами. Хоть в комментарии, хоть в доке. Это будет куда более полезно, чем идеальное имя класса полученное усилиями 10 людей из телеграм-чата по архитектуре
DT
Как по мне, в вашей любви к совершенству вам нужно помнить о разумных пределах. И, возможно, не заниматся овернеймингом в пользу утопичной понятности будущему поколению, которое будет работать с этим кодом. Ну и не забывайте о возможности поработать над документацией и граммотно описать эту часть системы, если уж вы так всё вылизиваете. Лично я бы сказал спасибо за хорошую доку, а не за крутой нейминг
С документацией есть одна проблема. Она устаревает сразу как только заканчивается работа с ней
MG
Эта проблема есть у всего и она поддаётся управлению
k
Это объект, который содержит первичные данные после проверки токена во внешней системе. Нужен он в единственном экземпляре в одном лишь месте от мидлвары до мидлвары. Но в нём есть свойства в отношении многие ко многим, в мидлваре требуется проверить наличие нужных свойств и в случае успеха разделить коллекции уже отдельными свойствами для модели пользователя.
Я из любви к совершенству спросил, так сказать. Сделать как-нибудь-то я всегда успею. А поскольку все имена конвенциональны, то их нельзя вывести как-то логически, они результат прозрачности коммуникации и осведомлённости о её состоянии. Можно назвать по-своему и тебе может казаться, что ты офигеть как очевидно выразился, но другой человек придёт и будет твой ребус разгадывать)) Поэтому я спросил, вдруг есть, что предложить. Потому что подобные ситуации часто возникают, кругом объект на объекте, но хочется отделить один объект от другого по часто фигурирующим признакам.
Я из любви к совершенству спросил, так сказать. Сделать как-нибудь-то я всегда успею. А поскольку все имена конвенциональны, то их нельзя вывести как-то логически, они результат прозрачности коммуникации и осведомлённости о её состоянии. Можно назвать по-своему и тебе может казаться, что ты офигеть как очевидно выразился, но другой человек придёт и будет твой ребус разгадывать)) Поэтому я спросил, вдруг есть, что предложить. Потому что подобные ситуации часто возникают, кругом объект на объекте, но хочется отделить один объект от другого по часто фигурирующим признакам.
звучит как чёт типа TokenVerified
ЕЧ
звучит как чёт типа TokenVerified
Ну, я не в том смысле, как вообще имя подобрать, а в том, можно ли отнести это к каким-то известным устоявшимся штукам, чтобы имя в итоге было TokenVerifiedDTO или DTO\TokenVerified, допустим. Я знаю, что есть те, кто против указания в имени разных патернов, особенно в мире java, но мне кажется, что это интуитивный вопрос перегиба палки, и как говорится, во всём надо меру знать
ЕР
Это объект, который содержит первичные данные после проверки токена во внешней системе. Нужен он в единственном экземпляре в одном лишь месте от мидлвары до мидлвары. Но в нём есть свойства в отношении многие ко многим, в мидлваре требуется проверить наличие нужных свойств и в случае успеха разделить коллекции уже отдельными свойствами для модели пользователя.
Я из любви к совершенству спросил, так сказать. Сделать как-нибудь-то я всегда успею. А поскольку все имена конвенциональны, то их нельзя вывести как-то логически, они результат прозрачности коммуникации и осведомлённости о её состоянии. Можно назвать по-своему и тебе может казаться, что ты офигеть как очевидно выразился, но другой человек придёт и будет твой ребус разгадывать)) Поэтому я спросил, вдруг есть, что предложить. Потому что подобные ситуации часто возникают, кругом объект на объекте, но хочется отделить один объект от другого по часто фигурирующим признакам.
Я из любви к совершенству спросил, так сказать. Сделать как-нибудь-то я всегда успею. А поскольку все имена конвенциональны, то их нельзя вывести как-то логически, они результат прозрачности коммуникации и осведомлённости о её состоянии. Можно назвать по-своему и тебе может казаться, что ты офигеть как очевидно выразился, но другой человек придёт и будет твой ребус разгадывать)) Поэтому я спросил, вдруг есть, что предложить. Потому что подобные ситуации часто возникают, кругом объект на объекте, но хочется отделить один объект от другого по часто фигурирующим признакам.
По описанию получилась просто какая-то структурка данных полученная в ответ от другой системы, а не объект с логикой
ЕР
Так что можно назвать, исходя из того что она содержит
SB
Ну, я не в том смысле, как вообще имя подобрать, а в том, можно ли отнести это к каким-то известным устоявшимся штукам, чтобы имя в итоге было TokenVerifiedDTO или DTO\TokenVerified, допустим. Я знаю, что есть те, кто против указания в имени разных патернов, особенно в мире java, но мне кажется, что это интуитивный вопрос перегиба палки, и как говорится, во всём надо меру знать
TokenVerifiedDtoClassCodeFile
ЕЧ
С дуру можно и сломать чего-нибудь. Известное дело)