Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Damat_AE, Вы писали:
D_A>> полностью типизированные методы
СГ>Вы хотите спросить почему используется обобщённый механизм посылки сообщений вместо механизма вызова соответствующих методов?
СГ>Ответ простой: добавить новый метод в уже опубликованный интерфейс нельзя, а добавить новый тип сообщения — запросто.
СГ>TYPE MyMessage = RECORD (Message) ... END;
СГ>VAR myMsg: MyMessage; СГ>... СГ>obj.Handle(myMsg);
СГ>Все старые модули при этом перекомпилировать не надо.
думаю в системе не должно быть меньше модулей чем 3 и не больше чем мало
все это хорошо в приложении с плагин архитектурой, там только так, но длч обычного рода приложений — это отягощение.
возможно мы говорим о разных масштабах приложений? наверное, если оно огромное и содержит множество подсистем — имеет смысл,
но опять же, ядро системы должно предоставлять богатый интерфейс — контексты, а клиент просто с ними работает.
ну например, главное окно приложения — контекст, в котором крутятся плагины. Есть объекты в контексте для встраивания в меню,
работа со статус баром, доступ к документу.
как по мне, логика, обрабатывающая сообщения и их перенаправляющая — непомерно мала, чтобы ее реализовывать в качестве базовой.
я видел в интерфейсе класс Модель — походу от нее надо бы пронаследоваться походу, или контроллер наследуетс, или вью, или все
сразу. Это и есть ответ на то, что метод обработки сообщений на контроллере должен привести модель к конкретному типу — а он может
не совпасть.