Слишком ли это кривое решение?

Она так составлена дурацки

Это кстати упущенная возможность как мне кажется, если бы задачи шли парами, где в первой заставляют тебя реализовать функционал рагульно, как тут, а в следующей показали "а теперь смотри как надо". Люди бы сразу поняли прелести ООП :)

С высокими шансами не пройти чекер в итоге 🤦‍♂️ Пусть и выглядеть будет логично до поры до времени

Ты если что-то умное пытаешься сказать - говори так, чтобы тебя люди понимали :)

Ладно, сейчас понятно напишу. Готовы?)) Я не против, как могло показаться, доработки интерфейса Astronaut и использования его в цикле, поддерживаю удачную мысль. Но проверка задачи чекером JavaRush может быть неуспешной, хотя такая доработка и выглядит логичной, и коллега потратит дополнительное время на "исправление" кода. "До поры до времени" означает, что рано или поздно класс/интерфейс надо будет каким-то образом расширять под появляющиеся потребности. Это вот, что я пытаюсь вам сказать))

Проверка не будет успешной естественно, валидатор, в сущности являющийся набором тестов, ожидает что в коде есть и используются разные методы типа pilot, createDirection, research и все эти методы принимают аргументы конкретного подтипа (ведь принимай они тип Astronaut, зачем нужно было бы приведение типов?). Здесь как ни изгаляйся - не получится пропихнуть нормальное решение :) Я потому и говорю что задача имеет спорный образовательный характер и не плохо бы шла в паре с "правильной" реализацией.

А можешь, плиз, набросать код, как бы такое могло выглядеть, с "правильной" реализацией? Что-то похожее на эту задачу с астронавтами, но не прямо ее.

Да хотя бы так например Уже было бы бодрее :) Саму задачу про астронавтов я к сожалению не видел и скорее всего не увижу, можно предположить, что там работа производится в сервисном слое, методы которого почему-то сильно зависим от типа аргумента. Если тут используются какие-то внешние зависимости, таких которых у рабочего почему-то нет, то наверное это имеет смысл, но все равно дурно пахнет с точки зрения архитектуры. Можно было бы перекинуть их в абстрактного родителя например в виде DI, тогда наследники могли бы иметь к ним доступ и реализовывать логику на своём уровне. А если классы наследники прям так кардинально отличаются друг от друга, есть ли вообще смысл в общем интерфейсе?) ну в смысле это чисто контейнер получается. Но тогда есть смысл разнести работу каждого типа в отдельный же сервис, который бы работал с объектами конкретного типа, после чего собрать их в кучу и в ростере находить нужный. Например так. Но это уже просто proof of concept :) Можно даже так Целью абстракции и является построение системы максимально гибкой и расширяемой. Нужно тебе добавить завтра к астронавтам нового - это действие не должно заставлять тебя переписывать пол кодовой базы где идут вот такие валидации как в примере выше.

Спасибо! Саму задачу про астронавтов я к сожалению не видел и скорее всего не увижу Почему же? Любую задачу можно по ссылке вверху открыть? Задача по астронавтов

Да я ж без подписки тут уже пару лет, так что ни условий нифига не видно )

тут багато людей без підписки) *хник*