проект: "java-учебный лагерь, задание 02.00". структура кода, обработка исключений, JavaDoc

Если проводить код ревью всего кода, то в нем слишком много проблем, чтобы написать комментарии. Данная реализация должна была выглядеть хотя бы так (хотя доводить ее до идеала просто не хватило времени)

import java.io.File;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Scanner;
import java.util.function.Supplier;

public final class Program {

    private static final String STOP_WORD = "42";
    private static final Path RESULT_FILE = Paths
            .get("result.txt")
            .toAbsolutePath();
    private static final Path SIGNATURES_FILE = Paths
            .get("signatures.txt")
            .toAbsolutePath();

    public static void main(String[] args) {
        SignatureDictionary dictionary = new SignatureDictionary(
                SIGNATURES_FILE);
        FileSignatureReader reader = new FileSignatureReader(
                dictionary.getMaxSize());
        try (Scanner scanner = new Scanner(System.in)) {
            runLoop(scanner::nextLine, dictionary, reader);
        }
    }

    private static void runLoop(Supplier<String> supplier,
            SignatureDictionary dictionary, FileSignatureReader reader) {
        String input = "";
        while (!input.equals(STOP_WORD)) {
            try {
                input = supplier.get();
                if (input.isBlank() || input.equals(STOP_WORD)) {
                    break;
                }
                String signature = reader.readFileSignature(new File(input));
                dictionary.getFiletype(signature).ifPresentOrElse(
                        fileType -> {
                            FileUtil.writeString(RESULT_FILE,
                                    fileType + System.lineSeparator());
                            System.out.println("PROCESSED");
                        },
                        () -> System.out.println("UNDEFINED"));

            } catch (Exception e) {
                System.out.println("ERROR: " + e.getMessage());
            }
        }
    }
}

import java.io.IOException;
import java.io.UncheckedIOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;
import java.util.List;

public class FileUtil {

    private FileUtil() {
    }

    public static void writeString(Path path, String content) {
        try {
            Files.writeString(path, content,
                    StandardOpenOption.CREATE, StandardOpenOption.APPEND);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

    public static List<String> readAllLines(Path path) {
        try {
            return Files.readAllLines(path, StandardCharsets.UTF_8);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }
}

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.UncheckedIOException;
import java.util.HexFormat;

public class FileSignatureReader {

    private final int byteLimit;

    public FileSignatureReader(int byteLimit) {
        this.byteLimit = byteLimit;
    }

    public String readFileSignature(File file) {
        try (InputStream is = new FileInputStream(file)) {
            return HexFormat.of().formatHex(is.readNBytes(byteLimit))
                    .toLowerCase();
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

}

import java.nio.file.Path;
import java.util.Map;
import java.util.Optional;
import java.util.stream.Collectors;

public final class SignatureDictionary {

    private final Map<String, String> signatureToType;
    private final int maxSignatureLength;

    public SignatureDictionary(Path resultFile) {
        this.signatureToType = FileUtil.readAllLines(resultFile).stream()
                .map(String::trim)
                .filter(line -> !line.isEmpty() && line.contains(","))
                .map(line -> line.split(",", 2))
                .collect(Collectors.toMap(
                        parts -> parts[1].trim().replace(" ", ""),
                        parts -> parts[0].trim()));
        this.maxSignatureLength = signatureToType.keySet().stream()
                .mapToInt(String::length)
                .max()
                .orElseThrow();
    }

    public int getMaxSize() {
        return maxSignatureLength;
    }

    public Optional<String> getFiletype(String fileSignature) {
        return signatureToType.entrySet().stream()
                .filter(entry -> fileSignature.startsWith(entry.getKey()))
                .map(Map.Entry::getValue)
                .findAny();
    }
}

Если есть вопросы - спрашивайте, не стесняйтесь Да, я удалил комменты, просто потому, что теперь они не соответсвуют реальнрости

1. тут все верно - 8 версия давно устарела, писать на ней странно
2. поскольку функциональное программирование появилось в версии 8, то в настоящее время (ведь прошло много времени)уже довольно много кода написано именно таким образом, посему знание функционалки ультимативно, эти скилы нужно прокачивать однозначно
3. см.п.2
4. см.п.2
5. в целом стримы почти всегда будут выигрывать (не забывайте, что они еще и отлично и очень легко паралеляться, что в реальном мире с огромным количеством данных ой как не повредит). вместе с тем есть довольно большое количество интерфейсов, написанных довольно давно, с которыми не получится взаимодействовать через стрим. тут у вас не будет выбора. в целом на первых порах можете писать все, что получается на стримах. прокачаете навык функционалки, это не будет выглядеть как костыль, а со временем будуту чувствовать когда все таки рациональнее цикл
6. см.п.8
7. это ощибка моей среды разработки(я исправил это когда адаптировал код по версию 8). System.in закрывать не надо
8. разница между Supplier и переменной( когда мы говорим об этом в контексте передачи его как аргумент метода) в том, где имнно будет выполнено действие по получению этой переменной. роедставьте себе такую ситуацию. у меня есть метод "а" и 10 методов, которые вызывают метод "а". метода а в аргументах принимает обычный String, а не Supplier. это значит что все 10 методов должны получить String и передать его. а если в 8 из 10 методов возможно исключение? нам нужно 8 раз в разных методах обрабатывать одно и тоже исключение. в случае с Supplier вызов метода, который вернет нужный нам String, произойдет не именно в теле метода "а", поэтому мы пишем обработку исключений 1 раз в методе "а", а не 8 раз в каждом из методов. для нашего конкртеного случая это несущественно, но я хотел бы показать разницу между переменной и лямбдой (в контексте аргумента метода)
9. UncheckedIOException это непроверяемое исключение. все дело в том, что проверяемые исключения в целом были признаны как ошибочный шаг. их использование вызывает довольно много проблем. например, попробуйте вызвать методы, пробрасывающий проверяемое исключение, в стриме. вы увидите насколько кривая конструкция получится. посему UncheckedIOException это способ избавиться от костыльного проверяемого исключения IOException. не нужно маниакально менять все проверяемые исключения сразу, ведь далеко не всегда это будет вам мешать. вторая сторона медали - паттерны conroller (grasp) и facade(gof). по сути все сводится к изоляции взаимодействий с "внешним миром" и приведения к удобному интерфейсу. посмотрите на класс FileUtil. я взаимодействую с внешним миром - файловой системой. а внешний мир - это всегда много проблем. если я размажу это взаимодействие по коду, а потом вдруг окажется что файловая система не всегда доступна и нужно реализовывать альтернативную логику на этот случай, то я попегу размазывать эту альтернативную логику по всему коду. вместо этого я сделал класс, отвечающий за такое взаимодействие и далее любые изменения взаимодействия с файловой системой будут влиять тольок на этот класс. кроме того, я одновременно избавляюь от неудобного для меня проверяемого исключения. теперь по поводу "почеиу просто не пробросить наверх". это хороший вопрос и не относится к проверяемым/непроверяемым исключениям никак: и те и другие пробрасываются наврех одинаково, разница только в том, нужно ли их декларировать в сигнатуре метода. а в целом общее правилопо исключениям состоит в том, что мы обрабатываем только то, что можем обработать корртекно. писать catch, который ловит exception и ничего не делает просто , чтобы не падало, это макстсмально плохое решение ибо теперь мы ничего не знаем о проблемах, которые есть, а код работает некорреткно. исправление такого кода займет намного больше времени,чем если бы прилетело обычное ислкючение.
10. это самый сложный вопрос , ответ на него придет с опытом. но!!! как вы уже видели, я выше ссылался на паттерны. так вот, принципы и паттерны очень помогут вам получить ответ на этот вопрос. итого, обратите внимание на принципы kiss, dry, yagni, также на паттерны grasp, кроме того, вы наверное слышали про solid, я бы сказал, что он говорит ровно о том же, что и grasp, но grasp, как мне кажется, для понимания проще. когда с этим освоитесь, посмотрите на паттерны gof. это поможет сделать ваш код лучше и критически смотреть на свой же код, не имея под рукой ревьюверов.

Кроме того, основные проблемы вашего кода не в циклах и прочих "точечных" изменениях. Почитайте про декомпозицию предметной области и еще раз обратите внимание на п.10. С этими знаниями начните с проектирования своего кода. программирование не начинается со среды разработки, оно начинается с проектирования, мбо весь код, который вы напишете "на колекне", вы гарантировано перепишите и не один раз. в этом нет смысла. нужно четко понимать какой класс за что отвечает и какие методы этого класса какие задачи выполняют. правильное деление на классы и методы в соответствии с указанными принципами/паттернами - ключ к хорошему коду Используйте ООП и ФП вместо процедурного программирования Избавляйтесть от статики! Это чуть ли не самое большое зло. Статикой должны оставаться утилитные методы (это не значит, что мы теперь делаем утилем вообще все), а также финальные переменные. в вашем коде почти все статическое. Старайтесь не изобретать велосипед. Делать то, что же сделано - задача неблагодарная. Используйте не те классы, которые вы хорошо знаете, потому что вы их хорошо знаете, а те, которые лучше подходят под задачу.