>Thank you very much for all the warm replies!
>
>I think the heart of the problem is the design in A. (it is doing too many things...)
>
>In fact both A and B are classes from Visual Promatrix, A is subjected to changes when the developer of VPM distributes newer version and as a user I am suppose/advised to make change at subclass level (that is the B).
>
>Anyway, in this case, it seems I won't be able to avoid changing A's Init method (knowing its last line DoDefault actually does something), since I can't avoid changing A's code, I have decided to go ahead and change it there and of course take a serious note in my documnetation in case I need to reapply the same modification.
>
>Again, thank you for all the guides!

I have no idea how responsive the promatrix guys are, but if you can offer reasonable explanation why they should change their code into the hook pattern they will probably think about it or at least offer an alternative method to reach your goal without you having to create "bad stuff". Keep in mind that they must keep the code of all their customers running, so think about what you propose. Especially in Fwks somtimes code in the base classes works for different branches you are not thinking of in your personal bind.

If that is not possible or they are unresponsive, I'ld probably bite into the bad apple, copy all the code and change the dodefault() into fwk_parentclass::init(), so that afterwards on fwk updates I'd only have work if the method changes in the fwk. Only as last resort, though.

HTH

thomas