Comments 8
Вы не поверите, есть ещё процедурный способ передачи управления. И ещё командный.
Фаулера в литературе забыли, причём и про проектирование, и про UML
Пример со статистикой и графикой, имхо, не корректный — статистика это модель (про которую вы вообще забыли :( а ведь самое интересное на мой взгляд творится именно там )
Пример со статистикой и графикой, имхо, не корректный — статистика это модель (про которую вы вообще забыли :( а ведь самое интересное на мой взгляд творится именно там )
Да, кинги Фаулера тоже будут, несомненно, полезны. Сейчас я как раз в процессе их изучения и не хочу рекомендовать то, что сам не прочитал. ГоФов и Буча вполне, имхо, достаточно, чтобы понять, что такое паттерны, и как их описывать на диаграммах классов.
Под статистикой я имел ввиду не модель, а контроллер, модуль, который занимается сбором и отображением статистики. Естественно, сами данные тоже должны где-то храниться, но то, как устроена модель не рассматривал специально, так как в примере хотел описать именно взаимодействие контроллера и представления.
Под статистикой я имел ввиду не модель, а контроллер, модуль, который занимается сбором и отображением статистики. Естественно, сами данные тоже должны где-то храниться, но то, как устроена модель не рассматривал специально, так как в примере хотел описать именно взаимодействие контроллера и представления.
А еще лучше, если у вас и задача отрисовки графиков, и задача подсчета статистики «логикоёмки», чтобы они друг о друге не знали вообще.
Задача организации взаимодействия в таком случае — это отдельная зона ответственности и лучше, когда её выполняет отдельный объект. Как доп. плюс в этом случае — взаимодействие лучше продумывается, и идёт обмен законченными структурами данных, а не «по кускам». И тестируются обе части замечательно.
Но это, конечно, применимо не в случаях, где и View и контроллер достаточно сложны.
А статья хороша, хотя бы как повод вспомнить о «добром и вечном» :)
Задача организации взаимодействия в таком случае — это отдельная зона ответственности и лучше, когда её выполняет отдельный объект. Как доп. плюс в этом случае — взаимодействие лучше продумывается, и идёт обмен законченными структурами данных, а не «по кускам». И тестируются обе части замечательно.
Но это, конечно, применимо не в случаях, где и View и контроллер достаточно сложны.
А статья хороша, хотя бы как повод вспомнить о «добром и вечном» :)
Что-то не особо понятно чем же все таки отличается событияная модель передачи от объектной. С помощью объектов можно довольно многое моделировать, события в том числе. В вашем примере Boss зависит от EventHandler. В том что он в свою очередь ссылается на метод а не на объект не имеет никакого значения для Boss. Boss мог бы быть Observeble и в методе startProject просто вызывать notifyObservers(). Разницы вызывать метод notifyObservers или projectStarted.Invoke(this, new EventArgs()) с точки зрения дизайна никакой.
Речь не о том, как моделировать передачу управления. Действительно, разницы между объектами-наблюдателями и вызовом метода из делегата .NET с точки зрения факта передачи нет никакой. На самом деле, делегат — это тоже объект. Названия выбраны скорее из идеологических соображений =)
Разница же в области видимости и связанности объектов. Посмотрите картинку про Неизвестность и SomeClass. В этом и отличие — событиями мы оповещаем неизвестных подписчиков, а вот через интерфейсные методы позволяем этим же незнакомцам управлять собой. Повторюсь, как эта идея реализована технически, разницы нет.
Наверное, все-таки название «объектный способ» выбрано неудачно и только запутывает. Может, кто подскажет более подходящее?
Разница же в области видимости и связанности объектов. Посмотрите картинку про Неизвестность и SomeClass. В этом и отличие — событиями мы оповещаем неизвестных подписчиков, а вот через интерфейсные методы позволяем этим же незнакомцам управлять собой. Повторюсь, как эта идея реализована технически, разницы нет.
Наверное, все-таки название «объектный способ» выбрано неудачно и только запутывает. Может, кто подскажет более подходящее?
Sign up to leave a comment.
Способы передачи управления между программными объектами