Thought of one more option. I haven't looked at the code, but I'm guessing that currently, PlainBaseDialog is a direct subclass of WindowBase and DialogControl is a subclass of some sort of control base. In that situation, then WindowBase is the first class in the inheritance tree where the two meet. As a result, WindowBase has implemented a number of things that only apply to "dialog-like" entities, but don't apply to all the rest of the things that subclass WindowBase. getTextSize() certainly seems to fit into that category. ooRexx has a good solution here...use some multiple inheritance! Refactor all of the methods that only apply to dialog-like things into a mixing class, then have both PlainBaseDialog and DialogControl inherit that mixin-class. You'll still want to have these written in a way where the inheriting class cooperates with the mixing class to get things done. By that, I mean having methods like getDialogParent() that isolates the determination of which window is the "parent" for things like getTextSize().
Ok, I just reread your original post, and I realize now that WindowBase is already a mixin. This makes life easy! Just create a DialogBase mixin that's a subclass of WindowBase and just shuffle the dialog-centric methods out of WindowBase. Rick On Wed, Jan 14, 2009 at 11:21 PM, Mark Miesfeld <miesf...@gmail.com> wrote: > On Wed, Jan 14, 2009 at 7:57 PM, Mark Miesfeld <miesf...@gmail.com> wrote: >> On Wed, Jan 14, 2009 at 6:54 PM, Rick McGuire <object.r...@gmail.com> wrote: >> >>> Well, the best design pattern for something like this would be not do >>> the test for the control type, but have a method call at the point >>> where you need to distinguish between the objects and have the >>> dialogcontrol override that method to produce the different behaviour. > > Going back to this a bit. (I'd really like to learn more about good > object orientated design. And have been passing up a good opportunity > by not asking more questions. <grin>) > > Here we have this existing design > > ::class WindowBase public mixinclass object > > ::class PlainBaseDialog public ... inherit WindowBase > > ::class DialogControl public ... inherit WindowBase > > The implementation of getTextSize() works fine as long as the object > is either a dialog control or a dialog. But what if a user who > doesn't understand the internals well does something like this: > > ::class MyMenu public subclass object inherit WindowBase > > menu = .MyMenu~new(...) > size = menu~getTextSize(...) > > Now, the implementation of getTextSize() can't possibly work. That > was the situation I was trying to avoid by doing something like: > > if self not PlainBaseDialog and self not DialogControl then raise > syntax exception > > Then if the user did inherit from WindowBase he couldn't call > getTextSize(), he would need to over-ride it with his own > implementation if he wanted that method. > > Should you just trust the user of the classes to not do something > foolish, or ... ? > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
