В Java, когда один интерфейс расширяет другого, почему можно было бы повторно объявить метод в подынтерфейсе?
У вас есть проблемы с сервалом здесь
1.При создании другого byte[] array - newDirectoryByteArray. Кажется ненужным, вы можете просто написать
_Filestream.Write(testAsBytes, 0, testAsBytes.Length);
2. Когда вы записываете в файл, курсор перемещается вместе с ним, если вы хотите использовать тот же FileStream для чтения из файла, вы должны искать желаемое местоположение. То есть до _Filestream.Read(...) вы должны позвонить, например. Filestream.Seek(0, SeekOrigin.Begin);
Из MSDN
Если операция записи выполнена успешно, текущая позиция потока увеличивается на количество записанных байтов. Если возникает исключение, текущая позиция потока не изменяется.
blockquote>
- строка
data = Encoding.ASCII.GetBytes(charBuffer, 0, 1).ToList();будет всегда возвращает 0, потому что данные не записываются вcharBuffer. Ваши данные находятся вbuffer, который будет соприкасаться с 1 по индексу 0 и 0 по всем другим индексам, вы можете видеть, что с помощью
Console.WriteLine(buffer[0]);вы получите 1 иConsole.WriteLine(data[0]);выдаст 0
5 ответов
Видя, что это происходит при случае при работе на Sun, я могу сказать Вам, как это обычно происходит. Кто-то определяет интерфейс, скажем, Alice, с некоторыми методами; многие разработчики реализуют тот интерфейс.
Некоторое время спустя понято, что им нужен некоторый другой интерфейс, назовите это Bob, который имеет подмножество методов Alice, чтобы позволить этому служить основным интерфейсом для другого интерфейса, Clara.
При перемещении методов Alice в Bob Вы взламываете весь код, который реализует Alice; необходимо возвратиться и по крайней мере перекомпилировать целый набор кода, некоторые из которых Вы не можете владеть, и по политическим причинам, не может повредиться.
Таким образом, Вы не делаете.
В Java 5 можно изменить тип возврата метода переопределения путем создания этого более конкретным. Чаще всего документация отличается, таким образом, метод должен быть объявлен снова.
Однако, если метод и документация являются тем же, нет никакой потребности в нем. Однако Вы будете видеть много кода, который не строго необходим. Возможно, что это было необходимо однажды, но что-то было изменено так, это больше не необходимо. Довольно вероятно, что это никогда не было необходимо, но было сделано, потому что разработчик думал, что что-то должно было быть сделано, когда на самом деле не было хорошей основы для него.
BTW: у Различных людей есть другие взгляды на то, что необходимо или удобно, чтобы иметь или лучше сделать явным.
Я никогда не видел, что польза рассуждает для этого. Лучшее, которое я видел, то, что:
- Это проясняет, что это, не имея необходимость видеть родителя
- Это помогает изменить то, что класс расширяет, не имея необходимость выяснять то, что взаимодействует через интерфейс, это должно реализовать
Мне не нравится ни одно предложение. Я думаю, что вероятная причина состоит в том, что, в то время как код писался, интерфейсы были записаны, прежде чем абстрактные классы и разработчики не потрудились удалять дублирующиеся реализации.
Никогда не недооценивайте лень разработчика :-)
В конце не причинен никакой вред за исключением того, что во время загрузки класса он, вероятно, берет незначимую часть времени дольше для загрузки класса дублирующимися интерфейсами.
Я сказал бы "нет", нет никакой причины сделать это. Я могу вообразить пару путями, это могло произойти во время эволюции некоторого кода все же. Весьма распространено взять существующий интерфейс и вытащить меньший суперинтерфейс из него. При том обстоятельстве я могу предположить оставлять существующий интерфейс, но просто изменять его для расширения от нового интерфейса.
единственная причина, из которой я знаю, состоит в том, чтобы расширить видимость метода (т.е. клон от защищенного до общественности), но это, кажется, не имеет место здесь.