> Feel free to suggest how to use a trait such that I can pass
> the trait from a derived class to redefine the button controllers policy
> (when the button controller is a part of the base class).
Well that's not so hard. Store an abstract base ButtonControllerBase class
with the interface and then use the trait class to instantiate it.
But this demonstrates the power of the Controller-View separation; all the
Views do is call a ButtonController::valid() method. Changing the
ButtonController would lead to minimal changes in the GUI-specific Views.
> Another options is to have all the different policies as static
> objects somewhere. (what I really do no like is the delete &bp_ i see
> in some destructors)
Well, that's because you have a general aversion to using "delete" with
references. Only the ButtonController has access to bp_ and it MUST be passed
(with memory associated) to the ButtonController c-tor, so it is absolutely
ok to do this. I've read my Stroustrup, you know, so I'm an expert ;-)
A.
