Well, good oo design would not even put the getTextSize() method on the WindowBase in the first place. If it's an error to call it for anything other than PlainBaseDialog and its subclasses, then the first place it should be implemented should be PlainBaseDialog. A base class should NEVER be directly aware of its subclasses. The breaks the entire inheritance paradigm. I a good rule of thumb for an IsA() test is it should only ever be applied to arguments, not SELF. Special-casing of the class should be handled via appropriate method definitions and overrides.
Obviously, I don't have a lot of the context here, but my recommendation for designing this would be: 1) Create a BaseDialog class that's a subclass of WindowBase. PlainBaseDialog and WindowDialog will subclass this rather than WindowBase. 2) Move getTextSize() to BaseDialog, along with any other methods that only apply to Dialog-type windows. 3) Add a getParent() (or some other name) private method to PlainBaseDialog and DialogControl. getTextSize() calls this method and gets the appropriate return value for the type of control. If that's too much trouble, then just remove the definition of getTextSize() from WindowBase and add the definition directly to PlainBaseDialog and DialogControl, mapping to the same native method (you can do that). You'll still probably want to do the step in 3) to avoid needing to do the isA() call. The problem here is WindowBase is implementing things that don't really apply to all of its subclasses. With the legacy of how things used to be implemented, I think I can understand why. With the new APIs, it's easier to move the native methods around so they are only implemented in the places where they make sense. 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
