Why InputStream Design Is Wrong

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Не только InputSteam, но и этот класс - хороший пример плохого дизайна. Я говорю о трех перегруженных методах read(). Я упомянул эту проблему в разделе 2.9 Elegant Objects. Вкратце, я настоятельно считаю, что интерфейсы должны быть “функционально бедными”. InputStream должен был быть интерфейсом с одним методом read(byte[]). Затем, если его авторы хотели предоставить нам дополнительную функциональность, они должны были создать дополнительные “умные” классы.

Вот как это выглядит сейчас:

Что не так? Очень удобно иметь возможность считывать один байт, массив байтов или даже массив байтов с прямым позиционированием в определенное место в буфере!

Однако нам все еще не хватает нескольких методов: для чтения байтов и немедленной записи в файл, преобразования в текст с выбранной кодировкой, отправки по электронной почте и публикации в Twitter. Было бы здорово иметь такие возможности прямо в “пустом” InputStream. Надеюсь, команда Oracle Java уже работает над ними.

Тем временем, давайте посмотрим, что именно не так с тем, что эти талантливые инженеры уже разработали для нас. Или, может быть, позвольте мне показать, как я бы разработал InputStream, и мы сравним:

Это мой дизайн. InputStream отвечает за чтение байтов из потока. Для этой функции есть только один метод. Удобно ли это для всех? Он читает и публикует в Twitter? Пока нет. Нужна ли нам эта функциональность? Конечно, но это не означает, что мы добавим ее в интерфейс. Вместо этого мы создадим дополнительный “умный” класс:

Теперь мы хотим прочитать один байт из потока. Вот как:

Функциональность чтения одного байта находится за пределами InputStream, потому что это не его задача. Потоку не нужно знать, как управлять данными после их чтения. Все, за что отвечает поток, это чтение, а не разбор или манипуляции после этого.

Интерфейсы должны быть небольшими.

Очевидно, перегрузка методов в интерфейсах является “плохим запахом” кода. Интерфейс с более чем тремя методами - отличный кандидат для рефакторинга. Если методы перегружают друг друга, это серьезная проблема.

Интерфейсы должны быть небольшими!

Вы можете сказать, что создатели InputStream заботились о производительности, поэтому позволили нам реализовывать read() в трех различных формах. Тогда я должен спросить снова, почему бы не создать метод для чтения и сразу же опубликовать его в Twitter? Это было бы фантастически быстро. Разве это не то, чего мы все хотим? Быстрое программное обеспечение, которое никто не хочет читать или поддерживать.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 22:23

sixnines availability badge   GitHub stars