2) С помощью метода UserNotificationRepository узнать, есть ли уже в БД для этого юзера уведомление с таким типом.
3) Если такого уведомления нет => создать его с помощью метода UserNotificationRepository
Зачем это проверять снаружи? Почему бы просто не сделать один метод для отправки уведомлений, который внутри проверит, не было ли оно отправлено раньше?
Михаил, вы меня не поняли.
Почему я предлагаю использовать здесь сравнение, вместо in:
1. Так производительнее, тк не нужно выделять память под списки и сравнивать число с каждым элементом списка.
Производительность будет важна при большом количестве вызовов
2. Сравнение с числами будет чуть ближе к правилам языка
3. Код никогда не будет переписан или изменён, тк в нём нет мест для возникновения багов или новых фич
4. замена списков на сравнение не ухудшит читабельность
Роми, емнип, в php можно функции отдельно писать, без класса - в таком случае реально хз, зачем нужны статические методы.
Мб дать какое-то глобальное состояние, которое будет доступно только изнутри класса.
Михаил, не читабельнее, тк совершенно не понятен смысл этих чисел.
Тем более этот код обычно всегда 1 раз в проекте пишут и никто туда больше не заходит.
Юра Майллер, тут всё-таки шестиугольники)
Если делаешь тайлы, то думаю полезно будет почитать статью Гексагональный тайловые миры
Там много математики, но это всё же правильнее подход, чем отдельно рисовать каждую клетку и состыковывать её с остальными.
Ну и пример там не на юнити, но думаю не сложно будет перенести.