Этот момент я понял, меня просто интересует сам момент объявления. Ведь по сути ArrayList и так наследник List, само объявление разве что-то меняет?

Апи более гибкое получается

с языка снял , никак не мог сформулировать))

Ты не сможешь методы arrayList использовать

В данном конкретном случае ничего. В случае отдельного метода, используя интерфейс ты даёшь клиенту право выбора реализации, а не жёстко ее зашиваешь

Только если закастить обратно к аррейлист

То есть, лучше стремиться к более гибкому функционалу и объявлять как List?

в целом через интерфейсы , но стоит учитывать ситуацию. Не всегда это хорошая идея реализовывать объекты через интерфейс

я так 2 дня над рабочим кодом сидел и гадал в чем проблема

Максимально гибкому, да. Возможно даже не list, а iterable :)

а проблема была в тестах)

Реши, какие методы от параметра тебе нужны и выбери максимально общий класс в котором они есть

Всем спасибо!)

Короч, мужики, дело такое.
Пишу игрового бота для Discord на JDA. Хочу всё структурировать, классифицировать по красоте, читаемости и расширяемости с учётом принятых в джаве стандартов оформления кода (в которых ничего не понимаю, лол, поэтому и пишу сюда).
У меня есть главный класс Bot, в котором объявлено поле private Commands activeCommands, оно передаётся объекту BotListenerAdapter extends net.dv8tion.jda.api.hooks.ListenerAdapter, который передаётся JDABuilder'у при создании объекта JDA. Commands — это просто обёрточка над HashSet<Command> с дополнительным функционалом для быстрого поиска нужной команды и всяким таким. Command — это абстрактный класс, от которого наследуются разные команды и реализуют соответствующую логику.
По задумке BotListenerAdapter обрабатывает получение сообщения в канале через @Override onMessageReceived, проверяет наличие команды в activeCommands и вызывает у неё метод action (тот самый абстрактный метод с логикой), передавая параметры команды, после чего метод action отрабатывает и возвращает некий результат, который там же в обработчике onMessageReceived бот должен отправить ответом в канал дискорда Ну, чтобы не передавать в объект команды всякую муть, вроде объектов канала, отправителя и т.д. Команда отработала автономно, а ответом занимается уже BotListenedAdapter, получив её результат.
Проблема вот в чём: результат исполнения команды может быть разный. Это может быть как plain-text-ответ или DiscordEmbed или какая-нибудь гифка, так и более сложная конструкция, напичканная всякими фьючерами (или потоками, хз), представляющая из себя Embed с функциональными кнопками, реализованными через reactions дискорда. Естественно, разные виды результатов и обрабатывать нужно по-разному. Как быть в таком случае? Каким образом лучше всего будет классифицировать результат исполнения Command.action и как отличить один вид результата от другого?

Была идея написать enum CommandResult с несколькими константами, определяющими разные виды результатов и эксклюзивными данными и методами для разных констант, но... как-то слегка отдаёт это костылём. Предусмотрены ли в джаве более подходящие и уместные способы реализации данной штуки?

Кто может подсказать, где можно попрактиковаться в многопоточности?

Может задачник какой-то есть)

Присоединяюсь к вопросу

блинов

Книга