Почему бы не реализовать StringBuilder и StringBuffer общий интерфейс? [закрыто]

В настоящее время этот вопрос не подходит для нашего формата вопросов и ответов. Мы ожидаем, что ответы будут подкреплены фактами, ссылками или опытом, но этот вопрос, скорее всего, вызовет дебаты, аргументы, опросы или расширенное обсуждение. Если вы считаете, что этот вопрос можно улучшить и, возможно, снова открыть, посетите справочный центр для получения рекомендаций.

Закрыт 7 лет назад .

Различия междуStringBuilderиStringBufferв Java хорошо документированы и затронуты в StackOverflow .

По сути, StringBuilderявляется несинхронизированной -копией StringBufferс почти таким же интерфейсом, поскольку он был задуман как более быстрая замена -вместо StringBuffer. Их API практически идентичен, и они фактически являются подклассами одного и того же недоступного абстрактного класса в текущем JDK.

Единственное, о чем я задаюсь вопросом, так это о том, почему они не публично связаны . Было бы разумно, если бы оба класса реализовали общий интерфейс или даже StringBufferв качестве подкласса StringBuilder.допуская существование общего кода для обоих классов.

Так почему же это вынужденное разделение? Было ли это сделано для того, чтобы программисты случайно не перепутали безопасный для потоков -код с небезопасным для потоков -? Или это была просто дизайнерская оплошность, которая теперь будет унаследована до конца вечности?

РЕДАКТИРОВАТЬ:

Чтобы прояснить ситуацию, :я могу размышлять о том, почему все так, но я надеюсь на конкретные ссылки на фактическое решение, например. во время процесса JSR. Все, что могло бы пролить свет на ситуацию, которая, на мой взгляд, иногда вызывает определенные трудности.

РЕДАКТИРОВАТЬ 2:

Тот факт, что оба класса реализуют Appendable, совершенно вылетел из моей головы. Вероятно, потому что этот конкретный интерфейс бесполезен для большинства целей -, он может добавить только один символ или подготовленный объект, и все. В большинстве случаев это не более полезно, чем то, что оба класса являются подклассамиObject.

РЕДАКТИРОВАТЬ 3:

Ну, вот обоснование именно этого вопроса из полу -официального источника:

Оценка группы библиотек:

По замыслу StringBuffer и StringBuilder не имеют общих общий общедоступный супертип. Они не предназначены для использования в качестве альтернативы :. error (StringBuffer ), а другой (StringBuilder )— его замена.

Ясно, что отсутствие общего супертипа может в некоторых случаях замедлить надеялся -на переход от StringBuffer к StringBuilder. Обратная сторона заключается в том, что, добавляя общий супертип, мы будем учитывать ошибки нашего прошлое и закрепление их в общедоступном интерфейсе, чтобы быть с нами для всех время. Это не только замедляет миграцию :, но и срывает ее.

задан Community 23 May 2017 в 12:08

0 ответов

Другие вопросы по тегам:

design-patterns java stringbuffer stringbuilder

Почему бы не реализовать StringBuilder и StringBuffer общий интерфейс? [закрыто]

0 ответов

Похожие вопросы: