Главный вопрос так и остался - выделять ли под монету сущность
Я тебе уже дал ответ. Вести лог. С датами. С монетами. С назначением платежа.
Размышления на тему заводить или не заводить сущность - это вопрос эстетики.
Можешь заводить если она тебе так сильно нужна. Можешь почиать про шаблон
проектирования Flyweight https://en.wikipedia.org/wiki/Flyweight_pattern это на тему
экономии ресурсов.
Но мне кажется что тут первичный вопрос какова стоимость поисковой операции монет
по пользователю а не вопрос ООП-эстетики.
Я-бы голосовал сразу против Python. Без типизации новичок очень долго не понимает зачем она будет нужна потом в других языках. Тоже самое что стартовать с изучения JavaScript. Для профессионалов которые уже знают десяток языков - этот факт не имеет значения. Но как точка старта - Python плох.
Илья, преподаватель должен был тебе объяснить когда используется рекурсия. В чем ее преимущества.
Нельзя просто так, немотивированно "захотеть" и что-то делать.
Я предпрениматель, у меня свои программисты.
.....
Существует много готовых кодов, частей программ или целиком, как искать,
теститировать, находить то что да можно использовать?
Твои программисты должны уметь находить нужный код. Это не твоя задача.
k_f_i, тогда проще сделать так. Не удалять точки и пробелы и прочее. А выделить только поток цифр. А потом расставить где надо точки. По сути отформатировать длинное число.
с 02.12.2022 г. по 26.07.2023 г. => с 0212202226072023 => 02.12.2022 26.07.2023
Вобщем неправильный этот сайт. Не советую им пользоваться. Область определения ключа - гораздо шире
чем строка символов. В идеале - это массив байтов (битов). Но с байтами как всегда есть проблема. Их неудобно
представлять в виде букв. Нужен encoder типа base32/base64/base85. А этот дешевый сайт просто решил
пренебречь этим фактом.
А ты не груби, когда тебе задают уточняющий вопрос. По твоему я должен был твои баги воспроизводить
чтобы увидеть скрытый текст?
На больших расстояниях я рассматривал коня как корабль который может плыть по 8 азимутам. 30 градусов. 60. 120. 150 и так далее. Тут - как-бы ни у кого вопросов не возникает. Конь-корабль. Плывет быстро. Но грубо. Может промахнуться. Как быть чтобы не промахнуться.
Далее.
Для близких я рисовал матрицу дистанций в ходах. Для 1 коня получается 5х5. Вот типа такого.
4 1 2 1 4
1 2 3 2 1
2 3 0 3 2
1 2 3 2 1
4 1 2 1 4
Вот. Если конь стоит в центре матрицы то расстояние от него до самого себя - 0 шагов. И так далее.
Теперь грубый алгоритм коня-корабля можно совместить с точной подгонкой коня под конкретную координату.
Этот точный алгоритм можно решать через BFS с ограничением в глубину 4 хода.
UPD:
Короче мой поинт в том чтобы не мучать BFS а просто использовать 2 алгоритма последовательно. Надеюсь автор меня услышит.
Я тебе уже дал ответ. Вести лог. С датами. С монетами. С назначением платежа.
Размышления на тему заводить или не заводить сущность - это вопрос эстетики.
Можешь заводить если она тебе так сильно нужна. Можешь почиать про шаблон
проектирования Flyweight https://en.wikipedia.org/wiki/Flyweight_pattern это на тему
экономии ресурсов.
Но мне кажется что тут первичный вопрос какова стоимость поисковой операции монет
по пользователю а не вопрос ООП-эстетики.