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

A>Расписно конечно классно, но ни в OpenGL, ни в DirectX, ни даже в GDI это рисование не очень-то укладывается. Композитность конечно штука неплохая, и CompositeView объединяющий несколько View в данной задаче может быть пригодился бы, но в тоже время должен быть глобальный View — владелец IDirect3DDevice, hRenderingContext, PAINTSTRUCT или чего там надо. Вобщем некоторый контекст рисования в котором надо всё раз отрисовать. На карте я не могу отдельно перерисовать города, я вынужден перерисовать всё сразу. И кстати дорисовывать в несколько циклов рисования я тоже не могу. А у списка городов не так. И эти особенности IViewMap, IViewTowns, IViewSomethingElse о которых приходится знать презентеру, потому что теперь уже ему надо хранить этот контекст и передавать его разным IView. Либо создавать ещё какого-то отдельного RenderingContextManager. Я бы не назвал это самым удачным употреблением Flyweight.
И что тебе здесь не нравится? Выделения контекста вещь полезная. Поскольку в ней можно держать достаточно много простых хелперных функций. Например определения принадлежности координат региону.
A>Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.
Не всегда это есть верно. Даже скажу больше, чаще не верно. Чем меньше повторного кода, тем лучше контроль. Для уменьшения повторного кода нужна декомпозиция. А поскольку существует(а чаще всего неоправданная) боязнь сущностей, то так и появляется мусорка кода которую рефакторить принципиально невозмножно (как и определить чем эта мусорка в тот или иной момент занимается). Каждая программная сущность должна выполнять строго определенную задачу. И если четко выполнять данное предписание, то при рефакторинга ты получишь и MCV/MCP и другие паттерны. Но самое главное применение того или иного паттерна будет всегда оправданным.