Re: [Oorexx-devel] Some theory / philosophy on refactoring (existing public) classes

[Rick M. <obj...@gm...>]

This sounds good to me.  In general, if a method does not make sense
for a give class, then the appropriate error message should be "does
not understand".  In other words, the class should not have the method
in the first place.  If I understand your refactoring correctly, that
would be the net result, which would be a good thing.

Rick

On Mon, Sep 14, 2009 at 12:58 PM, Mark Miesfeld <mie...@gm...> wrote:
> I'm looking for a little help, advice, or maybe even a flat out "you
> can't do that" concerning the possibility of refactoring some of the
> ooDialog classes.
>
> Specifically, I would like to move some methods out of the
> AdvancedControls mixin class back to the DynamicDialog class.
>
> The DynamicDialog class has the methods that allow a dialog template
> to be built in memory, by the Rexx programmer.  It has methods like
> addButton(), addListBox() that add dialog controls to the template.
>
> The AdvancedDialog class has methods that allow the use of, what was
> probably at the time "newer" controls, like the Tree-view control.  Of
> course today these "newer" controls are far from new.  But the class
> also has several methods, like addTreeControl() that really should
> have been in the DynamicDialog classe.  Because:
>
> The DynamicDialog class has all the implementation code for managing
> the in memory template, which is needed by addTreeControl().  The
> functionality of adding a dialog control to the in memory template is
> the functionality of the DynamicDialog class.  All dialog classes that
> have the ability to use this functionality have inherited the
> DynamicDialog class already in the ooDialog framework.
>
> On the other hand, the AdvancedControls class is not inherited by any
> class in the framework, it is up to the user to inherit if from the
> user's subclass.  Which means the user can inherit the class in
> dialogs that do not support the building of the in memory template.
> In these cases, if the addXXXControl() methods are invoked they fail
> with raised exceptions, because the methods have to invoke
> DynamicDialog methods which are not available.  The AdvancedControls
> class *is* inherited by dialog subclasses that do not support the
> building of the in memory template, because the functionality it
> provides, that of working with "new" controls, is useful to all
> dialogs, whether they are "user defined" dialogs or not.
>
> If I moved these methods out of the AdvancedControls class into the
> DynamicDialog class, where I think they belong, in all programs where
> the methods currently work, they would still work.  In all programs
> where the methods currently don't work, they would still not work.
>
> Any thoughts on this?
>
> --
> Mark Miesfeld
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>