триггер на остановку цикла. Можно ретёрн прям внутри фора воткнуть, не принципиально. Просто ретёрн внутри фора вынудит писать два ретёрна.
Я думаю, ты усложнил) По какой-то привычке) Ведь будет более читаемо, если мы просто пробежимся по массиву, и вернем, если есть, а после цикла (если тот не вернул), вернем ответ
Чем плохо два return?)
в подходе) когда пишешь метод на множественные проверки, и в первой версии метод имеет условно 5 ретёрнов, а потом тебе надо расширить метод (по солиду же работаем!), то расширяешь по той же архитектуре до 6, 7 ретёрнов. А потом через пару месяцев там уже 20 ретёрнов. И тут ХРЕНАКС чёт отвалилось. На каком-то ретёрне. На каком - сидишь, дебажишь, разбираешься чё там 2 месяца назад в башке было, когда решил, что 5 ретёрнов это нормально...
В данном случае - ничем
А теперь поднимемся на уровень абстракции выше, по тому же солиду. Метод у тебя делает что-то одно, и вряд ли там добавится так много ретернов, ведь ты пишешь атомарно, и в случае чего, ты добавишь новый метод
Добавлять новый метод на ту же задачу это уже нарушение принципа DRY)
Смотря в каком контексте
а вот тебе и контекст подъехал - обработка локаций
Нет. Например можно добавить метод Try
Абсолютно точно
На каждый новый уровень по новому методу?
И будет у тебя на каждый кабинет по методу. А потом вязанка из 100 методов, которые делают одно и то же. Оно того стоит?
Точно стоит. Ведь когда бухгалтерия будет ругаться на бизнес процессы из отдела ценообразования - будет такое себе
Через год они у тебя будут совершенно разными
И будет у нас по 100 методов на получение координат локации, по 100 методов на добавление сотрудников в локацию, и так далее?
Не путай расширение и изменение. Добавить return - изменить, а не расширить.
а что тогда будет расширением?
Обсуждают сегодня