Я смотрю у вас рефакторинг на уровне кода, который можно отловить анализатором. А у меня прямо на уровне архитектурных паттернов с полной заменой кусков, потому что разобраться невозможно.

Maccimo 2 мар в 01:31

в диапазоне от «ваш проект попахивает» до надо «<a href="/the-sin-of-refactoring" rel="noopener noreferrer nofollow">срочно все переписать</a>».

Это переработанная и обновленная версия статьи, оригинал которой доступен в нашем блоге.

Ссылки перед публикацией проверять надо.

       File f = new File(image);
        if (f.exists() && f.isFile() && f.canRead())
            return Files.readAllBytes(f.toPath());

Вроде бы про code smell и рефакторинг пишете и при этом смешиваете NIO с совершенно тут не нужным File.

        final List<String> resources = new ArrayList<String>
                                  (Arrays.stream(IMAGES).toList());

Ну и нафга тут стримы, чем вам Arrays.asList() не угодил?
Ещё зачем-то это сверху отдельно в ArrayList укутываете. На фоне разговоров про «так писали раньше» видеть игнорирование diamond operator несколько странно.

Отказ от модификатора public в интерфейсах вещь сомнительная сама по себе. В классах такие методы буду package-private, в интерфейсах — public, но кто-то почему-то решил что держать в голове дополнительный контекст это удобно. Зато не владеющим слепым десятипальцевым меньше буковок набирать. Популизм как он есть.

aleksandy 2 мар в 15:47

Ещё зачем-то это сверху отдельно в ArrayList укутываете

Имеет смысл, если требуется получение модифицируемой коллекции. Arrays.asList() таковой является лишь в части замены имеющихся элементов.

alex0x08 2 мар в 05:11

Вроде бы про code smell и рефакторинг пишете и при этом смешиваете NIO с совершенно тут не нужным File.

Первый раз слышу такой упрек, в чем проблема?

final List<String> resources = new ArrayList<String> (Arrays.stream(IMAGES).toList())

Все ради сохранения сигнатуры функции, которая возвращает итератор, на более глубоких стадиях рефакторинга очевидно это было бы убрано.

Отказ от модификатора public в интерфейсах вещь сомнительная сама по себе.

Умножайте приведенное место на тысячу и думаю вопрос будет исчерпан. Когда исходного кода много, любой способ его сократить является правильным.

Ссылку поправил, спасибо.

Maccimo 4 мар в 08:56

Все ради сохранения сигнатуры функции, которая возвращает итератор

Не ясно, зачем тут Stream API и почему IMAGES это массив. Вы могли сразу написать IMAGES = List.of() и всё. Ну или использовать всё тот же Arrays.asList(IMAGES) для инициализации resources , если IMAGES в виде массива строк всё же нужен отдельно.

Первый раз слышу такой упрек, в чем проблема?

Заменяем f.exists() на Files.exists(), f.isFile() на Files.isRegularFile(), f.canRead() на Files.isReadable() и единственным, из-за чего мы создавали экземпляр File остаётся вызов f.toPath(), который можно заменить на Path.of().

Таким образом, пакет java.nio.file предоставляет полноценную замену для java.io.File, причин для использования одновременно и java.io.File и java.nio.file.* по-просту нет.

Статья ведь про рефакторинг, логично сразу делать нормально.

alex0x08 4 мар в 09:07

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

В рамках статьи я рефакторил лишь один метод, а уровень бардака там такой, что переделывать надо 90% кодовой базы.

Maccimo 4 мар в 21:27

Я посмотрел на Bios.java и метод getBiosData() в нём единственный, который использует java.io.File. Речи про «не использовать ничего из java.io.* вообще» не шло.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий