Как стать автором
Обновить

Комментарии 9

Хотя мне не приходилось использовать CharSequence, его метод subSequence можно использовать в качестве view над оригинальным объектом, чтобы не плодить ещё. String так и делает.
Если я правильно понял, о чем вы, то нет — String так не делает начиная, кажется, с 7ой версии Java. При вызове substring он скопирует обозначенный кусок массива символов.

Все так, но то речь про String, а собственная реализация CharSequence действительно может делать и view оригинального объекта (если вдруг по каким-то причинам это принципиально в рамках проекта).
Что касается примера в статье в интерфейсе DefaultCharSequence — там идет сначала преобразование в String.

Пардон, и правда…
тот самый конструктор
    public String(char value[], int offset, int count) {
        ...
        this.value = Arrays.copyOfRange(value, offset, offset+count);
    }



Как-то даже стыдно, ни разу не сталкивался с подобным. Видимо, всё время везло
Мне представляется использование термина «скаляр» в данном контексте не очень уместным. Скаляр в физике — это например длинна или площадь фигуры на плоскости, которые не зависят от определённых изменений системы координат. Как я понимаю, Вы добивались:
1) Неизменности обьекта
2) сравнения по контенту
Этого со строками можео добиться меньшими усилиями.
Мне представляется, это порочный путь — брать сложный контракт (interface) и неявно предпологать, что только его часть будет реально использоваться. Разве Вашему классу ClientId нужно имплементировать charAt()?

Здесь скорее речь про математический скаляр как отображение один-к-одному ClientId<->String. И скаляр как одномерная величина в противовес вектору (многомерный). Классические примеры скаляров — числовые и строковые типы.
Имплементация charAt() — это часть имплементации интерфейса CharSequence и именно этот факт дает возможность использовать объект как строку. Конкретно нужен не метод, но реализовать интерфейс частично не выйдет. Если например кидать в реализации charAt() UnsupportedOperationException, то некоторое строковое api будет вылетать, к примеру Pattern.matcher(cliendId).

Разумеется понятно, что надо имплементировать все методы интерфейса. Мне представляется странным, что Вы берёте стандартный интерфейс, половина которого Вам не нужна, вместо того чтобы определить свой с минимально необходимым количеством методов.
Тем не менее, я с интересом прочитал вашу статью. Спасибо.

Я бы с удовольствием взял и собственный интерфейс, но ведь стандартная библиотека java и spring-jdbc ничего про них не знают.

Про математический скаляр. Я считаю, что использование нерелевантных понятий — одна из главных причин возникновения ошибок в программных системах. Поэтому хочу подробнее обьяснить моё возражение против этого термина в Вашем контексте.
С моей точки зрения скаляр в математике указывает на отсутствие внутренней структуры объекта. Из скаляров строятся вектора и более сложные математические структуры.
Суть CharSequence, с моей точки зрения — это представление сложных символьных обьектов как вектора символов. Поэтому скаляр здесь не очень уместен.
Вот если бы Вы строку заменили бы на её хэш…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации