Мы не можем создать экземпляр java.io.FilterInputStream, поскольку он не имеет открытого конструктора, нам даже не нужно его расширять.Почему FilterInputStream не является абстрактным классом
Почему они не сделали это абстрактным классом?
Технически protected в Java включает в себя как подклассы данного класса, и других классов (не обязательно подклассов), которые находятся в том же пакете. Таким образом, для другого класса в java.io можно было бы непосредственно создать экземпляр FilterInputStream. Единственная причина, по которой я могу подумать, почему вы хотите сделать это, - это то, что FilterInputStream.read(byte[] b) делегирует this.read(b, 0, b.length), а не delegate.read(b), поэтому это способ предотвратить вызов вызывающего метода делегата read(byte[]). Но это все спекуляции с моей стороны.
Кроме этого конкретного случая, как вы заметили, эффективно аннотация, но он не имеет абстрактных методов, поэтому компилятор не требует, чтобы класс был объявлен абстрактным.
Это все еще не отвечает, почему это не абстрактно. Если это вообще не требуется, то оно должно быть абстрактным для ясности. –
мой вопрос: они могли бы сделать это прямолинейно, просто написав «абстрактный», почему они пишут protected FilterInputStream (InputStream in) { \t this.in = in; } –
@ rakeshmalik91, даже если объявлено аббревиатурой, ему все равно понадобился бы конструктор, принимающий поток делегатов. –
мы не можем создать экземпляр java.io.FilterInputStream, как это не имеет открытый конструктор
Мы не можем. Классы в одном пакете могут.
FilterInputStream не имеет открытого конструктора (он защищен - вы можете видеть javadoc), поэтому вы не можете его напрямую создать. Поскольку у меня есть исследования, что DataInputStream происходит от FilterInputStream (и DataInputStream имеет открытый конструктор), поэтому он может быть создан.
Мы не можем сказать вам, почему они спроектировали его таким образом. Любой, кто это делает, дает только мнение ... если только они не были в команде дизайнеров. Я ожидаю, что реальный ответ заключается в том, что API был спроектирован в спешке, и как только недостатки были реализованы, было слишком поздно исправлять их. –
@StephenC И дизайн этого конкретного класса был выполнен примерно в 1996 году, а Java по-прежнему шутил :) –
Чтобы быть откровенным, я лично даже сомневаюсь в самой причине существования FilterInputStream. Класс добавляет * nothing * значения IMO, поскольку он не добавляет ничего, что позволяет взаимодействовать с потоком, который еще не является частью API InputStream. – Durandal