Поведенческий шаблон Observer предоставляет компоненту возможность гибкой рассылки сообщений зарегистрированным получателям.
На некотором объекте сконцентрировано внимание наблюдателей, заинтересованных в получении от него какой-то информации. Потребовав от наблюдающих объектов, чтобы они устанавливали сеансы связи с центральным объектом, можно значительно снизить накладные расходы на коммуникацию, т.к. устанавливать связь будут только объекты, заинтересованные в получении обновленной информации. Гибкость шаблона позволяет применять его для рассылки информации как отдельным, так и всем компонентам системы.
В соответствии с этим шаблоном, генераторы сообщений (наблюдаемые компоненты) рассылают сообщения, которые представляют события в системе. Эти события обрабатываются одним или несколькими получателями сообщений (компоненты-наблюдатели). Наблюдаемые компоненты отвечают за доставку событий всем заинтересованным наблюдателям (т.е. тем, которые установили сеансы связи). Интерфейс передачи сообщений позволяет наблюдаемым компонентам детализировать события для наблюдателей.
Если наблюдаемый объект многопоточный, он может поддерживать очередь сообщений, приоритеты сообщений, перекрытие сообщений и т.д.
Шаблон можно изменить, чтобы наблюдатели самостоятельно получали сообщения: наблюдаемый объект извещает о том, что событие произошло, а заинтересованные наблюдатели вызывают метод наблюдаемого для получения дополнительной информации о событии.
Аннотация – средство, которое позволяет встроить некоторую информацию (метаданные) в исходные и исполняемые файлы.
Аннотироваться могут классы, методы, поля, параметры, константы enum и сами аннотации.
Политика удержания аннотации определяет, на каком этапе аннотация отбрасывается. Определены три политики:
SOURCE – аннотации удерживаются только в исходном файле,
CLASS – аннотации сохраняются в файле .class во время компиляции, но недоступны JVM во время выполнения,
RUNTIME – аннотации сохраняются в файле .class и доступны во время выполнения.
Механизм рефлексии – позволяет обрабатывать типы, отсутствующие при компиляции, но появившиеся во время выполнения программы.
Рефлексия и наличие логически целостной модели выдачи информации об ошибках дает возможность создавать корректный динамический код
RTTI позволяет получить информацию о точном типе объекта, когда имеется лишь ссылка базового типа. Использование этой информации подразумевает отказ от всех преимуществ полиморфизма. Рекомендуется использовать именно полиморфные методы, а к RTTI обращаться только в крайнем случае.
Различие между механизмом RTTI и рефлексией состоит в том, что при использовании RTTI файл .class открывается и анализируется компилятором, а при использовании рефлексии файл .class открывается и обрабатывается системой выполнения.