Разве ObjectInputStream не должен расширять FilterInputStream?

Question

Цитаты блока взяты из Документов Java -

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

DataInputStream позволяет приложение читает примитивные данные Java типы из основного входного потока машинно-независимым способом.

Следовательно, DataInputStream расширяется FilterInputStream

ObjectInputStream десериализуется примитивные данные и объекты ранее написанный с использованием ObjectOutputStream.

Однако по какой-то причине ObjectInputStream НЕ расширяет FilterInputStream, хотя он также считывает объекты (на этот раз, а не примитивные типы) из основного входного потока. Вот ветвление соответствующих классов.

Есть ли конструктивное обоснование того же самого?

Answer 1

толковый вопрос. Думая об этом, я полагаю, что Object*Stream, возможно, был разработан, чтобы расширить Filter*Stream (то же самое относится к Выходу или Входу). Почему этого не было сделано? Возможно, потому что:

1. Это не дает никакой реальной выгоды. Как объяснил Мачей, смысл Filter*Stream, кроме неважной организации классов, состоит в том, чтобы обеспечить некоторую общую (и довольно тривиальную) реализацию реализации тех классов, которые шаблон (чтение / запись из некоторого базового потока, в конечном итоге преобразующий поток), который должен быть расширен другими классами (из Java API или пользователя). Но Filter*Stream не относится к интерфейсам : вы почти никогда не найдете и не реализуете какой-либо метод, который требует, например, Filter*Stream в качестве аргумента. Следовательно, решение о том, чтобы сделать класс наследуемым *Stream или Filter*Stream, когда есть альтернатива, в основном является решением о реализации; пользователи класса в основном не заботятся.

2. Дизайнеры ObjectOutputStream решили предоставить дополнительную гибкость тем, кто желает расширить класс, полностью переопределив его, предоставив дополнительный пустой конструктор (без базового OuputStream). Эта особенность (я думаю, довольно редко) ставит класс (концептуально и с точки зрения реализации) далеко друг от друга Filter*Stream. Опять же, это не кажется убедительным.

Answer 2

Существует различие между:

• Логическое наследование (интерфейс общих ресурсов)
• Наследование «Код» при совместном использовании кода между классами

ЛогическиLinkedList не является AbstractList, поскольку оно не абстрактно.Однако, с точки зрения кода, выгодно поделиться некоторой реализацией методов List, поскольку они могут быть реализованы в терминах других, обычно с той же эффективностью (например, isEmpty может быть реализовано как size() == 0).

Некоторые платформы, такие как GObject (или в некоторой степени Haskell - хотя это не язык ОО и многие вещи совершенно разные), допускают реализацию методов по умолчанию в интерфейсе, который его определяет.

Однакоэто не относится к Java, который использует классы Abstract* для повторного использования кода.Filter*Stream не столько определяет, что выходные данные отправляются куда-то (поскольку весь смысл ввода / вывода Java заключается в том, что производителю / получателю все равно), но он используется для повторного использования общего кода.

Answer 3

Я думаю, ObjectInputStream должен был переопределить каждый метод FilterInputStream.

Когда вы делаете это, на самом деле нет смысла поддерживать это отношение.

Что важно: ObjectInputStream IS InputStream (вы по-прежнему можете записывать в него примитивные данные в дополнение к другим методам), и эта связь существует.