1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/wizardforcel-thinking-in-java-zh

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
В этом репозитории не указан файл с открытой лицензией (LICENSE). При использовании обратитесь к конкретному описанию проекта и его зависимостям в коде.
Клонировать/Скачать
11.4 总结.md 4.9 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 11.03.2025 09:15 d56454c

11.4 Подведение итогов

Использование RTTI позволяет получить информацию о типах с помощью анонимной ссылки на базовый класс. Однако именно эта возможность делает его легко доступным для неправильного использования новичками, поскольку в некоторых случаях достаточно полиморфных методов. Для тех, кто привык к процедурному программированию, легко организовать свой код в виде последовательности switch-выражений. Они могут использовать RTTI для этого, что приведёт к потере важных преимуществ полиморфизма при разработке и поддержании кода. В Java требуется максимально использовать полиморфизм, используя RTTI только в особых случаях.Однако для использования полиморфизма требуется контроль над определением базового класса, так как иногда может оказаться, что базовый класс не содержит необходимых методов в рамках программы. Если базовый класс получен из библиотеки или контролируется чем-то другим, то использование RTTI (Run-Time Type Information) является хорошим решением: можно расширить новый тип и добавить свои методы. В других частях кода можно будет определять специфический тип и вызывать этот специальный метод. Это не нарушает полиморфизм и способность программы к расширению, так как добавление нового типа не требует поиска switch-выражений в коде. Однако если требуется добавить новые возможности в основном коде, то потребуется использование RTTI для определения своего специального типа.С точки зрения интересов конкретного класса, добавление характеристики в базовый класс может означать, что все производные от него классы получат некоторую бесполезную "нагрузку". Это делает интерфейсы запутанными. Если кто-то наследует от этого базового класса и обязан переопределить абстрактные методы, это может создать проблемы. Например, представьте, что мы используем структуру классов для представления музыкальных инструментов (Instrument). Предположим, нам нужно очистить спит-вэлвы всех подходящих музыкальных инструментов в оркестре. Один способ сделать это — добавить метод ClearSpitValve() в базовый класс Instrument. Однако это может создать путаницу, так как это подразумевает наличие спит-вэлвов у ударных и электронных инструментов. В этом случае RTTI предлагает более логичное решение, помещая метод в конкретный класс (например, Wind, то есть "духовой"). Однако более разумным решением было бы поместить метод prepareInstrument() в базовый класс. Новички обычно не видят этой необходимости и считают, что им следует использовать RTTI.

Наконец, RTTI иногда может использоваться для решения проблем эффективности. Если код широко использует полиморфизм, но один объект имеет очень плохие показатели производительности, можно использовать RTTI для определения типа этого объекта и затем написать специализированную реализацию для повышения его эффективности.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/wizardforcel-thinking-in-java-zh.git
git@api.gitlife.ru:oschina-mirror/wizardforcel-thinking-in-java-zh.git
oschina-mirror
wizardforcel-thinking-in-java-zh
wizardforcel-thinking-in-java-zh
master