Не я проектировал апи (: Я это лишь переписываю. Там один путь - устаревшая версия второго. И его держат на случай, если вдруг кто ещё этим подьзуется
Почему просто не сделать два метода - один из них просто вызывает другой и больше ничего не делает. Обычный же рефакторинг для поддержания легаси-интерфейса объекта, зачем мучать киску
Почему просто не сделать два метода - один из них просто вызывает другой и больше ничего не делает. Обычный же рефакторинг для поддержания легаси-интерфейса объекта, зачем мучать киску
Потому что на стадии ревью вопрос возник. Зачем тут лишний метод который ничего не делает, кооме как вызывает другой метод. Так бы я конечно 2 метода сделал и не парился (:
Потому что на стадии ревью вопрос возник. Зачем тут лишний метод который ничего не делает, кооме как вызывает другой метод. Так бы я конечно 2 метода сделал и не парился (:
Потому что на стадии ревью вопрос возник. Зачем тут лишний метод который ничего не делает, кооме как вызывает другой метод. Так бы я конечно 2 метода сделал и не парился (:
Затем, что для сохранения совместимости? Странноватый вопрос.
Затем, что для сохранения совместимости? Странноватый вопрос.
Вопрос был не в этом совсем. А в том, что нечего делать 2 метода, когда лучше было бы на один метод все пути повесить. Меньше кода -> меньше проблем и проще разобраться
Вопрос был не в этом совсем. А в том, что нечего делать 2 метода, когда лучше было бы на один метод все пути повесить. Меньше кода -> меньше проблем и проще разобраться
Ну метод, который делегирует всю работу другому - это не то чтобы много кода
Вопрос был не в этом совсем. А в том, что нечего делать 2 метода, когда лучше было бы на один метод все пути повесить. Меньше кода -> меньше проблем и проще разобраться
Нет, меньше кода - не меньше проблем и проще разобраться, если это "меньше" кода сложнее (а это очень часто так - самый банальный пример такого - регулярки)
Нет, меньше кода - не меньше проблем и проще разобраться, если это "меньше" кода сложнее (а это очень часто так - самый банальный пример такого - регулярки)
Если регулярки, то тут уже вопрос к правильному структурированию данных
Нет, меньше кода - не меньше проблем и проще разобраться, если это "меньше" кода сложнее (а это очень часто так - самый банальный пример такого - регулярки)
Нет, меньше кода - не меньше проблем и проще разобраться, если это "меньше" кода сложнее (а это очень часто так - самый банальный пример такого - регулярки)
В данном случае сложность не особо возрастёт, если добавится одна аннотация
Нет, меньше кода - не меньше проблем и проще разобраться, если это "меньше" кода сложнее (а это очень часто так - самый банальный пример такого - регулярки)
регулярки проще байткода в разы, а тем не менее в байткод все почему-то любят лазить, если конечно это не байткод регулярок)