Здравствуйте, Greg Zubankov, Вы писали:

GZ> bool SetRect(Rect const&); // bool для уведомления о результете изменения успех/неудача
GZ> bool SetState(State);
Какая может быть неудача и какая логика на этом может быть построена?

GZ>В случае с кнопкой интерфейс представления будет состоять из функций для отображения кнопки на экране, запроса на перерисовку кнопки и событий оповещающих Presenter о движении мыши и нажатиях на кнопки мыши (клавиатурные команды для простоты рассматривать не будем).
GZ>Получается так:
Не совсем. Обычно все-таки интерфейс View полее высокоуровневый, все эти отслеживания мыши и прочую конкретику берет на себя библиотека отображения. Интерфейс вью проще — нажали/не нажали, скрыли/показали, Enable/Disable, задали текст/изображение..

GZ>Тут у меня появляется небольшое недопонимание. Помимо вышеперечисленных функций Презентеру (поскольку он управляет логикой контрола) может понадобиться CaptureMouse и ReleaseMouse для корректного перехода из состояния в сотояние.
Нет, не понадобится, это забота View, так как все это конкретика определенного отображения на определенном устройстве.

GZ> Выходит Презентер должен знать об особенностях конкретного представления, оконной библиотеки?
Нет конечно.

GZ>// пример реализации одной из функций
Нет, призентер ничего не знает о конкретных кнопках мыши или клавиатуры. К нему просто приходит извещение о том, что состояние кнопки изменилось. Каким способом это произошло — его не интересует, это забота вью.
Забота презентера — изменить модель в соответствии с этим изменением и, возможно, изменить другие представления, то есть, довольно высокоуровневая логика.

GZ> Если владелец кнопки захочет изменить ее местоположение или (пусть даже так) состояние, функциями какого класса он будет пользоваться?
Все изменения модели происходят через соответствующий презентер.

GZ> Но ведь у нее нет уведомлений представлению или презентеру об изменении. Что необходимо сделать? Добавить SetRect, SetState к Презентеру, Реализации вида или уведомления модели?
Дело в том, что изменение модели, как правило, происходит не само по себе, а по причине того, что случилось какое-то внешние событие. Все внешние события проходят через презентер, соответственно соответствующий презентер знает о том, что модель поменялась. И обладая этим знанием может уведомить другие презентеры или View о том, что он что-то менял.
Это при условии, что мы хотим оставаться в рамках пассивной модели, однако ничто не запрещает реализовать и активную модель, если так удобнее.. Хотя на мой взгляд, лучше оставаться до самого последнего момента в рамках пассивной модели.

GZ>Также много вопросов возникает по взаимодействию триад MVP. Можете посоветовать конкретные примеры, в которых не сложно будет разобраться?
Ну, есть несколько ссылок в статье... В последнее время ничего по этой теме нового не попадалось.