Почему я должен заботиться о RTTI в Delphi?
Я услышал много о новых/улучшенных возможностях RTTI Delphi 2010, но я должен допустить свое незнание... Я не понимаю это. Я знаю, что каждая версия Delphi поддерживала RTTI..., и я знаю, что RTTI (Информация о типах во время выполнения) позволяет мне информации о типе доступа, в то время как мое приложение работает.
Но что точно, который означает? Действительно ли поддержка RTTI 2010-х Delphi является тем же самым как отражением в.NET?
Кто-то мог объяснить, почему RTTI полезен? Притворитесь, что я - Ваш заостренный волосатый босс и помогаю мне понять, почему RTTI прохладен. Как я мог бы использовать его в реальном приложении?
5 ответов
RTTI в Delphi все еще не совсем так полнофункциональный, как Reflection в .NET или других управляемых языках, потому что он работает с скомпилированным кодом, а не с Промежуточный язык (байт-код). Однако это очень похожая концепция, и новая система RTTI в Delphi 2010 приближает ее на много к отражению, открывая весь объектно-ориентированный API.
До D2010 RTTI был довольно ограниченным. Единственное, что я когда-либо помнил, это преобразование перечислимого типа в строку (или наоборот ) для использования в раскрывающихся списках. Возможно, однажды я использовал его для постоянства управления .
С новым RTTI в D2010 вы можете делать гораздо больше:
Атрибут метаданные на основе (
TCustomAttribute).Типичными вариантами использования могут быть автоматическая проверка свойств и автоматическая проверка разрешений - две вещи, для которых вам обычно приходится писать много кода.Добавление поддержки активных сценариев (т. Е. С использованием элемента управления сценариями Windows)
Создание системы подключаемых модулей; вы могли делать это раньше, но было много головной боли. Мне не удалось найти действительно хороший пример того, как кто-то делал бы это сверху вниз, но все необходимые функции теперь доступны.
Похоже, кто-то даже пытается реализовать Spring (инфраструктура DI) для Delphi 2010.
Так что это определенно очень полезно, хотя я не уверен, насколько хорошо вы сможете объяснить это в PHB; большая часть его полезности, вероятно, будет реализована через сторонние библиотеки и фреймворки, почти так же, как это работает сегодня в сообществе .NET - редко можно увидеть код отражения в бизнес-логике, но типичное приложение будет использовать нескольких компонентов на основе отражения, таких как объектно-реляционный сопоставитель или контейнер IoC.
Я ответил на вопрос?
Большинство людей, вероятно, не будут использовать его в реальных приложениях.
Люди, которые будут его использовать, это сборщики фреймворка. Такие фреймворки, как DUnit, широко используют RTTI.
С новыми возможностями RTTI мы должны ожидать появления более продвинутых фреймворков и инструментов, похожих на те, что доступны для .NET. Эти фреймворки произведут большую революцию в вашем развитии, чем RTTI.
Расширенный RTTI в D2010 очень похож на отражение в C #. Это дает вам возможность получить доступ к любому полю объекта или проверить его методы. У этого есть все виды потенциальных применений. Например, если вы можете читать любое поле объекта, вы можете написать код сериализации, который может работать с любым объектом. А возможность проверять методы и получать их имя и подпись значительно упрощает регистрацию класса с помощью механизма сценариев.
Для меня это главное преимущество расширенного RTTI: возможность писать код, который работает с любым классом, проверяя его члены, вместо того, чтобы писать разные версии одного и того же кода снова и снова, адаптированные для каждого отдельного класса.
RTTI в Delphi всегда была важна с версии 1.0. Классические функции RTTI включают в себя раздел "опубликованные" свойства классов, что позволяло работать Объектному инспектору и функции времени проектирования компонентов. Для своих целей я часто использовал свойства "Published" классов, чтобы позволить перечислять эти свойства во время выполнения. Для хранения вещей с моих объектов на диск, для постоянства.
Delphi 2010 RTTI значительно расширяет эту классическую RTTI, настолько, что вы можете быть прощены за то, что думали, что у Delphi не было RTTI до Delphi 2010.
Я бы сказал, что наиболее полезными приложениями "The New RTTI" являются (как уже говорилось в некоторых ответах) фреймворки, написанные гуру, которые:
Справляются с персистентностью в файлах или базах данных. Фреймворки и компоненты для сохранения/загрузки баз данных и конфигураций или документов будут использовать это под капотом.
Обращаться с травлением/маркетингом/кодированием/декодированием к и от различных сверхпроводные форматы, такие как JSON, XML, EDI и другие.
Юнит-тестирование упоминалось кем-то еще (JUnit), но я думаю, что, возможно, те же самые фреймворки могут быть действительно удобны для отладки и инструментов сообщения об ошибках. Учитывая объект, переданный в качестве параметра, на стеке, почему бы не иметь сообщения об ошибках, которые могут выгрузить все данные, переданные в функцию, которая не справилась с задачей, а не просто список функций?
Как видите, некоторые креативные люди, скорее всего, придумают для этого еще больше применений. Можно сказать, что хотя это и не приводит к отражению четности в .NET (о чем больше говорит другой ответ), это все же приносит много возможностей "динамического языка" (Подумайте о Perl, Python, JavaScript) в мир систем статического типа Delphi, которые в противном случае были бы сильно типизированы.
Вы должны заботиться, потому что они положили это на коробку. Ясно, что они думают, что некоторым будет не все равно.
То, есть ли у вас какое-то применение, полностью зависит от характера ваших проектов. Так как у вас его раньше не было и вы не понимаете, почему наличие этого сейчас является преимуществом, это наводит на мысль, что вам это не нужно. Затем вам решать, тратить ли время на дальнейшее изучение предмета, чтобы выяснить, сможете ли вы найти ему применение.
Является ли это наиболее продуктивным использованием вашего времени по отношению к вашим проектам, опять же, это то, что можете знать только вы.