На предыдущем шаге есть такое требование:
В классе Room должен быть создан метод createMouse.
и такая рекомендация:
Метод createMouse не должен быть приватным.
Странно, как ты прошел проверку?:)
Приветствую, а можно вопрос по ООП.
Безотносительно вопроса , у меня такое же мнение нужно для валидации или нет, если мы конструируем объект, мы должны сначала завершить это , а потом в конструктор кидать, зачем чередовать.
Но вопрос возник.
Создается Змея, передается в конструктор Комнаты. В Комнате поле - змея. В это поле сетится ссылка на переданную змею. Окей.
Возвращаясь к методу мейн, мы начинаем ту змею модифицировать менять, но этот "пульт управления" указывает все на тот же объект, на который и указывает поле Комнаты типа змея?
То есть, мы сюда засетили:
publicclassRoom{privateSnake snake;
через конструктор, создался экземпляр класса, в котором это поле содержит ссылку на нашу Змею.
А потом в том же мейне:
snake.setDirection(SnakeDirection.DOWN);
то переменная snake ссылается на тот же объект что и вышеуказанное поле?
В моем понимании это как добавить объект в список. Мы же можем добавить объект в список, а потом отдельно заналлить его поля, ведь в списке просто указатель на место в памяти.
Объект один, а указателей-переменных может быть много получается?
Привет, да, всё верно, именно такие вещи зачастую нарушают принципы инкапсуляции, думаю здесь в идеале было бы написать
game =newRoom(20,20,newSnake(10,10));
game.snake.setDirection(SnakeDirection.DOWN);
Последовательность в решении автора тоже проблем создавать не должна, главное всё сделать до старта run(), но это если по логике , а вот с валидатором зачастую просто не угадаешь)
Лишняя переменная/ссылка тоже особо погоды делать не должна.
Со списками вообще нужно быть крайне осторожными, так как приватность вообще не обеспечивает безопасность содержимого, нужны unmodifiable
ух ты сколько приемчиков и интересностей , спасибо! Все в заметки записал :) Как раз недавно щупал unmodifiable/modifiable коллекции задавался вопросом к чему это все, теперь понятно.