Задача такая — рассылка сообщений одними объектами другим (или тем же) объектам. Число различных типов сообщений порядка 50 и их число может расти. Сообщения могут содержать много различной информации. Хотелось бы сохранять тип при пересылке, поэтому решено было внимательно посмотреть на TypedMessage (Влиссидес), в частности на вариант, где список наблюдателей поддерживается самим классом сообщения. Но тут встает проблема отсутствия статических полей у классов Делфи. Вместо них обычно применяются глобальные переменные, но в данном случае это будет выглядеть довольно-таки угрожающе — несколько десятков структур (скажем, списков), симантически никак не связанных с соответствующими классами, что, естесственно, чревато ошибками.
Вопрос такой: может быть есть удачные примеры реализации этого шаблона на Делфи?
Паттерн Observer. Subject — рассылаеющий обьект.Вариант 1. Таки брать информацию из сабжекта. Вариант 2. Параметр сообщения сделать ТОbjectom. И структур не будет и механихзм обсервинга менять не надо и можно расширять.
VS>Задача такая — рассылка сообщений одними объектами другим (или тем же) объектам. Число различных типов сообщений порядка 50 и их число может расти. Сообщения могут содержать много различной информации. Хотелось бы сохранять тип при пересылке, поэтому решено было внимательно посмотреть на TypedMessage (Влиссидес), в частности на вариант, где список наблюдателей поддерживается самим классом сообщения. Но тут встает проблема отсутствия статических полей у классов Делфи. Вместо них обычно применяются глобальные переменные, но в данном случае это будет выглядеть довольно-таки угрожающе — несколько десятков структур (скажем, списков), симантически никак не связанных с соответствующими классами, что, естесственно, чревато ошибками.
VS>Вопрос такой: может быть есть удачные примеры реализации этого шаблона на Делфи?
M>Паттерн Observer. Subject — рассылаеющий обьект.Вариант 1. Таки брать информацию из сабжекта. Вариант 2. Параметр сообщения сделать ТОbjectom. И структур не будет и механихзм обсервинга менять не надо и можно расширять.
1. Это не Observer.
2. Задача именно и состоит в том, чтобы отказаться от скрытия типа на этапе компиляции и убрать бесконечные проверки типа и приведения из слушателей.
На самом деле все прозрачно, но необходимость наличия кучи списков в одном файле (или, что еще хуже, нескольких десятков файлов на каждый тип сообщения) меня сильно настораживает.
VS>На самом деле все прозрачно, но необходимость наличия кучи списков в одном файле (или, что еще хуже, нескольких десятков файлов на каждый тип сообщения) меня сильно настораживает.
Может быть поэтому и настораживает ? Что оба варианта тебе не подходят ? ты проанализируй структуру сообщения и сопоставь с существующими классами. ТОгда , возможно родяться другие идеи. Подход с записями со сслылками на екземпляры объектом может тебе дорого стоить потом. Та и отладка такого приложения будет малоприятной.
