Если ее скопировать в Recipient wallet address окна send grams — то поля суммы и комментария — автоматически заполняются, ну и в поле адресата остается только адрес кошелька
По моему мнению, это обсуждение начинает скатываться в «холивар» по реализациям. Что, в свою очередь уведет от сути. Я специально в статье обходил, моменты, которые могут свести все к разнообразным «холиварам» не по теме.
В приведенном Вами примере, больше вопросов чем ответов. «Холиварных», вопросов.
Вопросы:
Интерфейс CustomerNameChangedEvent, какому пакету (модулю, банду, скопу) принадлежит? Сервису, который отвечает за изменение данных клиента?
Интерфейс SmsNotifyEvent, какому пакету (модулю, банду, скопу) принадлежит? Сервису, который отвечает за sms отправку?
Интерфейс LogChangesEvent, какому пакету (модулю, банду, скопу) принадлежит? Сервису, который отвечает за логирование?
По описанному вами коду, я вижу 3 разных задачи:. Изменение имени, смс информирование, и логирование. При этом основной задачей является изменение имени. Остальные второстепенные.
По вашему коду получаются связи: Клиент зависит от смс и логирования, что по мне в корне не корректно, так как связь должна быть обратной. смс и логирования может не быть, это второстепенный функционал.
Исходя из этого смс и логирования, должны быть слушателем, а не частью события на кейсе изменения имени клиента.
Поскольку, уже второй комментарий с упоминанием, передачи объекта по ссылке.
поскольку объекты всегда передаются по ссылке, пункт 1 это лишь частный случай пункта 2
Это верно, только когда передаваемые объекты содержат методы изменения данных. В случае простого DTO объекта, изменить, его нельзя.
Пример:
interface CustomerNameInterface {
public function firstName(): string;
public function lastName(): string;
public function middleName(): ?string;
}
interface customerNameChangedListener {
public function onCustomerNameChange(
int $customerId,
CustomerNameInterface $customerName
);
}
Это только оповещение, без возможности изменения переданного объекта.
interface customerNameBeforeChangeListener {
public function onBeforeCustomerNameChange(
int $customerId,
CustomerNameInterface $customerName
): CustomerNameInterface
}
Тут, явно описано, что обработчик может изменить объект, или даже подменить его реализацию.
И повторюсь, интерфейс CustomerNameInterface при разработке уже есть в системе, в описанном способе дополнительный объект «сахар» CustomerEvent не нужен.
ton://transfer/EQCWDQ-CsQyqzStKU6k50VYBamGSZ9flElNGjuonwGoQbxtr?amount=2000000000&text=Test%20invoice
0,005437 transaction fee 0,000000041 storage fee
0,0001 transaction fee 0,000000016 storage fee
0,0001 transaction fee
При попытке отправить 0,0000000 — окно крашится.
В приведенном Вами примере, больше вопросов чем ответов. «Холиварных», вопросов.
Вопросы:
По описанному вами коду, я вижу 3 разных задачи:. Изменение имени, смс информирование, и логирование. При этом основной задачей является изменение имени. Остальные второстепенные.
По вашему коду получаются связи: Клиент зависит от смс и логирования, что по мне в корне не корректно, так как связь должна быть обратной. смс и логирования может не быть, это второстепенный функционал.
Исходя из этого смс и логирования, должны быть слушателем, а не частью события на кейсе изменения имени клиента.
Это верно, только когда передаваемые объекты содержат методы изменения данных. В случае простого DTO объекта, изменить, его нельзя.
Пример:
Это только оповещение, без возможности изменения переданного объекта.
Тут, явно описано, что обработчик может изменить объект, или даже подменить его реализацию.
И повторюсь, интерфейс CustomerNameInterface при разработке уже есть в системе, в описанном способе дополнительный объект «сахар» CustomerEvent не нужен.