Поясните идеологию Java.nio на примере CharBuffer

@ptrts · Регистрация: 28.01.2013

Студворк — интернет-сервис помощи студентам

Долго думал почему в Java.nio почти все классы абстрактные, а подклассов ни у кого в документации не видно. Погуглил форумы, увидел что можно писать так:

Java
1
CharBuffer buf = CharBuffer.allocate(DEFAULT_BUFFER_SIZE);

Стало быть, думаю, возвращает что-то с не абстрактным подклассом этого самого CharBuffer

В отладчике посмотрел, возвращает нечто класса HeapCharBuffer. Который почему-то является каким-то секретным недокументированным подклассом CharBuffer.

Поясните пожалуйста, в чем смысл такой секретности?

@mutagen · 21.04.2013, 12:45

завтра придумают новую имплементацию например NewHeapCharBuffer и что вам лазить по всем кодам и переписывать под новую реализацию? Вы просто берёте новую версию JVM и делаете в ней то же что и в прошлой

Java
1
CharBuffer.allocate(BUFFER_SIZE)

и получаете новую возможно более лучшую в чём-то реализацию и вам не требуется менять код

@ptrts · 21.04.2013, 13:53 **[ТС]**

А зачем делать новую имплеменатацию с другим именем, но теми же методами?

@Севак · 21.04.2013, 16:13

ptrts, я думаю, что новые методы будут работать лучше, быстрее и т.д. иначе смысл их вообще делать

@ptrts · 21.04.2013, 17:44 **[ТС]**

Друзья, я уважаю ваш опыт, и прошу у вас прощения, но чувствую что вы говорите какую-то ерунду. Ну давайте тогда все паблик классы делать абстрактными, а пользовательский код будет работать с подклассами доступными только из классов пэкиджа

Есть абстрактный класс. Подклассы скрыты. Значит, работая с объектами любого из подклассов пользовательский код будет использовать ТОЛЬКО методы абстрактного суперкласса. И в чем тогда разница, если бы вместо абстрактного класса был бы просто нормальный паблик класс? Пожалуйста, пусть последующие JDK развивают его делают реализацию методов получше, в чем проблема?

@mutagen · 22.04.2013, 00:55

Да именно такая стратегия API и является на сегодняшнее время оптимальной, всё делается даже не через абстрактные классы а даже выше, через интерфейсы, таким образом вы себе оставляете лазейку на будущее изменить некоторые имплементации не ломая приложения, просто java обязанна быть совместима со своими старыми реализациями и поэтому часто вы видите реальные классы, а в этих реальных классах есть проблемы которые текущие разработчики новой JVM не могут исправить по причине потери совместимости. Поэтому это вовсе не ерунда а типичный энтерпрайз подход.

@ptrts · 22.04.2013, 06:35 **[ТС]**

Что-то я все же не понимаю, какую свободу данный подход дает авторам, если все равно они ограничены рамками суперкласса:

Убрать метод - нельзя

Добавить метод - нет смысла, его никто не увидит, так как публичным является только суперкласс

Добавить метод с другим набором параметров - тоже нельзя

Изменить реализацию метода - можно, как можно было бы и в случае если бы класс был один, публичный и не абстрактный

Так что же тогда кроется за формулировкой "изменить некоторые имплементации"?

Добавлено через 5 минут
Вот если бы подклассов было бы несколько, что при определенных условиях пользователю втихую подсовывался бы то один, то другой - было бы понятно. Но я проверил, и allocate и wrap создают все тот же HeapCharBuffer. Может как раз эту возможность разработчики оставили себе на будущее, добавлять другие подклассы? В остальном же смысла иметь абстрактный класс, у которого только один подкласс, хоть убей - пока не вижу. Хотя, готов и прозреть

@mutagen · 22.04.2013, 10:51

Сообщение от ptrts

что при определенных условиях пользователю втихую подсовывался бы то один, то другой - было бы понятно

так и происходит, но не в этом случае.
Я уже устал объяснять, не хотите понимать - но проблем, считайте всех вокруг дураками и пишите как хотите.

@ptrts · 22.04.2013, 11:19 **[ТС]**

mutagen, вы написали про "лазейку на будущее изменить некоторые имплементации не ломая приложения" и не объяснили в чем лазейка заключается

Я же задал вам еще вопрос: в чем лазейка?

Добавлять методы - нельзя, добавлять новые сочетания параметров - тоже нельзя, удалять методы - тоже нельзя. Переписывать реализацию методов - можно и так. Ну так и в чем лазейка тогда?

Грубо говоря, вы ответили "потому что так лучше", я же спросил вас чем конкретно лучше, и вышло значит так что я считаю всех дураками

@Skipy · 22.04.2013, 12:34

Сообщение от ptrts

А зачем делать новую имплеменатацию с другим именем, но теми же методами?

Пример. Интерфейс java.util.List. Методы можете посмотреть сами.

Реализации:

http://docs.oracle.com/javase/... yList.html
http://docs.oracle.com/javase/... yList.html
http://docs.oracle.com/javase/... dList.html
http://docs.oracle.com/javase/... Stack.html
http://docs.oracle.com/javase/... ector.html

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

Касательно исходного вопроса, почему сделано так. Потому что Вам нужен объект типа CharBuffer, а остальное Вам знать необязательно. Да, Вам вернулся HeapCharBuffer. А Вы абсолютно уверены, что при других условиях вернется экземпляр этого же класса? Представьте, что там штук пять реализаций, и решение, какую возвращать, принимается на основании каких-то критериев, о которых Вы ничего не знаете. Вот выставлен какой-то ключ оптимизации JVM - и она в этом месте создает другую коллекцию, оптимизированную нужным образом.

Такие вещи делаются сплошь и рядом. CharBuffer для этого не сильно удачный пример. А вот с тем же List - легко. Есть такой метод у Collections - synchronizedList(List), который возвращает синхронизированную оболочку для переданного объекта. Так вот, оболочка выбирается в зависимости от того, какой был исходный объект. Если он реализует один интерфейс - берется одна оболочка. Другой - другая. Третий - третья. Вам в эти тонкости вникать - только писать лишний код. И постоянно думать, как бы не запутаться. А когда реализаций от Вас скрывается - это в первую очередь для того, чтобы исключить лишние степени свободы.

@mutagen · 22.04.2013, 12:44

я не знаю - может так будет понятно, только не требуйте чтобы я вам рассказал всё по пунктам что лучше во второй имплементации

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
/**
 *
 * @author mutagen
 */
public class IOdd {
 
    public static void main(String[] args) {
        A a = new Aimpl1();
        System.out.println(a.isOdd(3));
        a = new Aimpl2();
        System.out.println(a.isOdd(3));
    }
}
 
interface A {
 
    boolean isOdd(int i);
}
 
class Aimpl1 implements A {
 
    @Override
    public boolean isOdd(int i) {
        return i % 2 != 0;
    }
}
 
class Aimpl2 implements A {
 
    @Override
    public boolean isOdd(int i) {
        return (i ^ 1) != 0;
    }
}

@ptrts · 22.04.2013, 13:05 **[ТС]**

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

@mutagen · 22.04.2013, 13:21

Сообщение от ptrts

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

а чё - самым умным быть довольно неплохо ))) я бы не отказался

@ptrts · 22.04.2013, 13:57 **[ТС]**

Ну... часто "самый умный" это не оценка мощи интеллекта, так сказать, а жизненная позиция))

Добавлено через 19 минут

Сообщение от Skipy

Касательно исходного вопроса, почему сделано так. Потому что Вам нужен объект типа CharBuffer, а остальное Вам знать необязательно. Да, Вам вернулся HeapCharBuffer. А Вы абсолютно уверены, что при других условиях вернется экземпляр этого же класса?

Если подклассов несколько - тогда нет вопросов, тогда абстрактный класс имхо имеет право на жизнь

Добавлено через 4 минуты

Сообщение от mutagen

я не знаю - может так будет понятно, только не требуйте чтобы я вам рассказал всё по пунктам что лучше во второй имплементации

Замечу что вопрос был не в том что такое доступ к объекту через интерфейс или суперкласс, а в том, зачем в упомянутой ситуации использовали эту методу, ну да ладно

@mutagen · 22.04.2013, 15:04

Сообщение от ptrts

Замечу что вопрос был не в том что такое доступ к объекту через интерфейс или суперкласс, а в том, зачем в упомянутой ситуации использовали эту методу, ну да ладно

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

Новые блоги и статьи Все статьи Все блоги /
сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и источниками (напряжения, ЭДС и тока). Найти токи и напряжения во всех элементах. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и. . .

@ptrts 8 / 8 / 0 Регистрация: 28.01.2013 Сообщений: 58
	21.04.2013, 13:53 [ТС]
	А зачем делать новую имплеменатацию с другим именем, но теми же методами? 0

@Севак любитель покушать 687 / 641 / 248 Регистрация: 25.09.2011 Сообщений: 1,313
	21.04.2013, 16:13
	ptrts, я думаю, что новые методы будут работать лучше, быстрее и т.д. иначе смысл их вообще делать 0

@ptrts 8 / 8 / 0 Регистрация: 28.01.2013 Сообщений: 58
	21.04.2013, 17:44 [ТС]
	Друзья, я уважаю ваш опыт, и прошу у вас прощения, но чувствую что вы говорите какую-то ерунду. Ну давайте тогда все паблик классы делать абстрактными, а пользовательский код будет работать с подклассами доступными только из классов пэкиджа Есть абстрактный класс. Подклассы скрыты. Значит, работая с объектами любого из подклассов пользовательский код будет использовать ТОЛЬКО методы абстрактного суперкласса. И в чем тогда разница, если бы вместо абстрактного класса был бы просто нормальный паблик класс? Пожалуйста, пусть последующие JDK развивают его делают реализацию методов получше, в чем проблема? 0

@mutagen 2587 / 2260 / 257 Регистрация: 14.09.2011 Сообщений: 5,185 Записей в блоге: 18
	22.04.2013, 00:55
	Да именно такая стратегия API и является на сегодняшнее время оптимальной, всё делается даже не через абстрактные классы а даже выше, через интерфейсы, таким образом вы себе оставляете лазейку на будущее изменить некоторые имплементации не ломая приложения, просто java обязанна быть совместима со своими старыми реализациями и поэтому часто вы видите реальные классы, а в этих реальных классах есть проблемы которые текущие разработчики новой JVM не могут исправить по причине потери совместимости. Поэтому это вовсе не ерунда а типичный энтерпрайз подход. 0

@ptrts 8 / 8 / 0 Регистрация: 28.01.2013 Сообщений: 58
	22.04.2013, 06:35 [ТС]
	Что-то я все же не понимаю, какую свободу данный подход дает авторам, если все равно они ограничены рамками суперкласса: Убрать метод - нельзя Добавить метод - нет смысла, его никто не увидит, так как публичным является только суперкласс Добавить метод с другим набором параметров - тоже нельзя Изменить реализацию метода - можно, как можно было бы и в случае если бы класс был один, публичный и не абстрактный Так что же тогда кроется за формулировкой "изменить некоторые имплементации"? Добавлено через 5 минут Вот если бы подклассов было бы несколько, что при определенных условиях пользователю втихую подсовывался бы то один, то другой - было бы понятно. Но я проверил, и allocate и wrap создают все тот же HeapCharBuffer. Может как раз эту возможность разработчики оставили себе на будущее, добавлять другие подклассы? В остальном же смысла иметь абстрактный класс, у которого только один подкласс, хоть убей - пока не вижу. Хотя, готов и прозреть 0

@ptrts 8 / 8 / 0 Регистрация: 28.01.2013 Сообщений: 58
	22.04.2013, 11:19 [ТС]
	mutagen, вы написали про "лазейку на будущее изменить некоторые имплементации не ломая приложения" и не объяснили в чем лазейка заключается Я же задал вам еще вопрос: в чем лазейка? Добавлять методы - нельзя, добавлять новые сочетания параметров - тоже нельзя, удалять методы - тоже нельзя. Переписывать реализацию методов - можно и так. Ну так и в чем лазейка тогда? Грубо говоря, вы ответили "потому что так лучше", я же спросил вас чем конкретно лучше, и вышло значит так что я считаю всех дураками 0

@ptrts 8 / 8 / 0 Регистрация: 28.01.2013 Сообщений: 58
	22.04.2013, 13:05 [ТС]
	Спасибо. Приду домой - буду вникать. Если что, я задаю вопросы не чтобы быть самым умным, а чтобы не упустить интересные приемы ООП 0