Тоже верно. Но с другой стороны, в этом и инкапсуляция. Кто-то вызывает геттер, не зная, как вырешивается значение. Таким образом, я могу позже добавить логику в сам геттер, не переписавая сами вызовы, коих к тому времени уже может быть много.
Спасибо за предложенный вариант.
Map наверное самый гибкий и удобный объект. Но опять таки слишком гибкий. Опечатки в ключах, захламление не используемыми данными и прочее. Тогда уж лучше взять Map<«Enum», Object>, чтобы хоть как-то обозначить границы и возможности.
Опять таки пример с билдером — всего лишь один из возможных путей решения. В реальном проекте кончено же, всё не просто проставляется. Те же цены, суммируются, сравниваются и прочее.
А вот из-за открытых полей с некоторыми коллегами можно и поссориться.
Спасибо за такой развёрнутый ответ.
Интересное, что у Вас сложилось именно такое мнение.
Наверное, мне надо было выражаться яснее.
Я не думаю, что кто-то из нас не сталкивался с императивным стилем программирования, т.к. именно с него обычно и начинается обучение.
Но Вы правы, не стоит слепо идти за каким-то стилем. Как я и сам уже сказал, главное, чтобы код работал.
Про тесты могу только уточнить, что я не писал, что не люблю тесты в целом. Лишь те, в которых идёт слишком сильная привязка на внутрености кода. Мне больше нравятся тесты наподобие «если я передаю А, то мне вернётся Б», нежели те, в которых проверяется, а был ли вызван такой-то сервис, с помощью того же Mockito.verify (необходимость таких тестов я не обсуждаю).
К слову о Mockito: я имел ввиду, что с помощью этого прекрасного инструмента можно написать тесты для функций, основанных на интрефейсах, не реализируя сами интрефейсы.
Против императивного программирования или любого другого абсолютно ничего не имею.
Скорее всего просто разница во вкусах и предпочтениях заставила меня, заострить внимание на этом коде. Совершенного кода просто не бывает.
Кстати, к var тоже сначала отнёсся скептически, когда их только аннонсировали. Сейчас понял, что они иногда неплохо облегчают жизнь. А тип подскажет IDE.
Ещё есть несколько идей по нескольким паттернам и архитектурам. Постараюсь и их изложить в подобной форме.
В каждом стиле есть свои преимущества и недостатки
Map наверное самый гибкий и удобный объект. Но опять таки слишком гибкий. Опечатки в ключах, захламление не используемыми данными и прочее. Тогда уж лучше взять Map<«Enum», Object>, чтобы хоть как-то обозначить границы и возможности.
Опять таки пример с билдером — всего лишь один из возможных путей решения. В реальном проекте кончено же, всё не просто проставляется. Те же цены, суммируются, сравниваются и прочее.
А вот из-за открытых полей с некоторыми коллегами можно и поссориться.
Интересное, что у Вас сложилось именно такое мнение.
Наверное, мне надо было выражаться яснее.
Я не думаю, что кто-то из нас не сталкивался с императивным стилем программирования, т.к. именно с него обычно и начинается обучение.
Но Вы правы, не стоит слепо идти за каким-то стилем. Как я и сам уже сказал, главное, чтобы код работал.
Про тесты могу только уточнить, что я не писал, что не люблю тесты в целом. Лишь те, в которых идёт слишком сильная привязка на внутрености кода. Мне больше нравятся тесты наподобие «если я передаю А, то мне вернётся Б», нежели те, в которых проверяется, а был ли вызван такой-то сервис, с помощью того же Mockito.verify (необходимость таких тестов я не обсуждаю).
К слову о Mockito: я имел ввиду, что с помощью этого прекрасного инструмента можно написать тесты для функций, основанных на интрефейсах, не реализируя сами интрефейсы.
Против императивного программирования или любого другого абсолютно ничего не имею.
Скорее всего просто разница во вкусах и предпочтениях заставила меня, заострить внимание на этом коде. Совершенного кода просто не бывает.
Кстати, к var тоже сначала отнёсся скептически, когда их только аннонсировали. Сейчас понял, что они иногда неплохо облегчают жизнь. А тип подскажет IDE.