when to use mvc++?

Well, since I used the design pattern proposed by Jaaksi MVC++, I said that really sucks, because sometimes it's really easy implement something connecting two controllers bypassing the main controller, especially when you know the entire software and you know that it will not change in the future (I'm talking about my project degree), but today I was walking to my home (yes it was raining and I was all wet) and start to think about the design of rizoma, and that application has a lot of UIs (notebooks, windows and dialogs) so the code it pretty ugly, so I started to think what to do if the application must be rewritten, and how to apply mvc++, and after a few blocks I said 'hey mvc++ rocks!', but why? ...

Let's see, when you have a software the will never have a final version (I mean that will never stop of being developed) you must use a modular design, and mvc++ give us that in a simple way.

Here are the main rules (IMO) of mvc++:

* There must exists a main controller and all the message that a controllers want to send to another one must pass across the main controller.
* A controller and view must have 1 to 1 relationship, so the view will only stay in touch with it's controller.
* The controller must provide a set of functionalities for the other controllers exposed by public methods.
* and of course the controllers can manipulate the model

The key to don't feel that mvc++ sucks, is don't think that when you are in a controller X you want/must call a method of controller Y, you must say 'hey, main controller, I want to use the A functionality, this are the arguments' and never think who is gonna receive those arguments, it's responsability of the main controller call the proper controller and pass the arguments in a way that it can understand.

With this change of think will let you have a pretty decent software, that can connect new UI components in a pretty simple way, and if you use the abstract partner it will be even better.