Почему Java .NIO использует методы stati c?

Question

Интересно, почему java .nio основан на методах stati c, я имею в виду, что в java .io вы создаете файл и затем используете его методы, это что-то вроде:

File file = new File("myFile");
FileReader fileReader = new FileReader(file);
BufferedReader bufferedReader = new BufferedReader(fileReader);
String readLine = bufferedReader.readLine();

Если каждый объект имеет свои собственные методы.

java .nio работает по-другому, вы используете методы stati c и вынуждаете вас всегда передавать файл для работы в качестве параметра.

Path file = Paths.get("myFile");
BufferedReader bufferedReader = Files.newBufferedReader(file);
String readLine = bufferedReader.readLine();

Path source = Paths.get("source");
Path target = Paths.get("target");
Files.copy(source, target);

Меньше кода для записи, поскольку nio предоставляет полезные методы (например, newBufferedReader) непосредственно в классе. но это можно было бы сделать и в методах экземпляра, чтобы вам не пришлось передавать путь в качестве параметра.

Почему это изменение парадигмы? Какие скрытые преимущества?

Answer 1

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

Это очень хорошо зарекомендовавший себя метод, позволяющий реализации быть гибкой в ​​том, какую реализацию она будет выполнять. на самом деле вернуться. Это позволяет инкапсулировать как сложную логику c, так и будущую эволюцию. Даже если это не относится к приведенным вами примерам, также возможно вообще не создавать новые экземпляры, а возвращать объединенные или кэшированные копии (как Integer.valueOf, а не new Integer).

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

Меньше кода для записи, поскольку nio предоставляет полезные методы (например, newBufferedReader) непосредственно в классе. но это можно было бы сделать и в методах экземпляра, чтобы вам не пришлось передавать путь в качестве параметра.

Что-то вроде path.newBufferedReader(), вероятно, слишком сильная связь между этими классами. Они хотят, чтобы Path был классом, представляющим путь к файловой системе. Ему не нужно знать все, что люди могут захотеть делать с файлами. Фокусированные и независимые классы помогают с модульностью.

Для более старых API, где они пошли другим путем, посмотрите на String#replaceAll. Здесь вся логика c понимания регулярных выражений была интегрирована в класс String.