Про задачу четвертого дня сказать особенно нечего. По условию – проще третей. По парсингу ввода – проще второй. Решается быстро.
Сразу прикинул, что с использованием примитивов или оборачиванием в типы из стандартной библиотеки – будет портяночно. Поэтому – отдельный класс с логикой:
И короткое решение с его помощью:
А если честно без условия задачи nextCards смущает, смысл есть ли в том что массивы идут по убыванию объема? Вопрос лишь к апи
И да понимаю что ссылки льшь будут, вопрос как собираешь, смысла их так хранить нету, у тебя вложенный массив почем зря получился, но опять вопрос апи, может там дерево и тогда место имеет право быть
Тут нет метрик (в advent of code) - по скорости, ресурсам и т.п.
Тут просто надо получить ответ, любым способом (народ в Гугл таблицах решает, в sed / awk и ещё кучей разных способов).
Поэтому я стараюсь соблюсти баланс между:
а) моими трудозатратами (есть по паре часов на задачку, несколько вечеров в неделю)
б) читаемостью (а я временами из прошлых задач копипащу что-то в новые - и не хочу долго вспоминать, что я там наворотил для "экономии памяти")
в) длинной самой портянки решения (т.к. всё в консоли - длинные листать неудобно, плюс я их в телегу закидываю - а там ограничение на длину поста)
По пункту в) - если что-то такое ещё реально вспомнить быстро и понять (https://dimio.org/advent-of-code-2022-day-19.html), то вот такое - я бы второй раз читать не хотел, после того, как написал (https://dimio.org/advent-of-code-2022-day-14.html или https://dimio.org/advent-of-code-2022-day-8.html)
Возвращаясь к вложенному массиву, с учётом вышесказанного - мне проще и короче в одном стриме его сохранить, развернуть все вложенные в общий стрим и сделать count.
Не могу утверждать, что это идеальный вариант :)
