How do you elegantly override a parent class’ settings and make use of them in inherited code? This isn’t particular to Xojo.
Let’s say I have a Canvas class with a long paint event. Call the class Flower. It has a colour constant used to paint the flower white.
I make a subclass called RedFlower. It overrides the colour constant to be red.
I don’t want to copy and paste the paint event. However, when my RedFlower calls paint, it used the parent’s paint event and also the parent’s white colour because the event is running in the parent.
How can the child use its own settings and elegantly use the parent’s paint event? (Assume there are many other settings/constants.)
Would it be better to use encapsulation and simply have a Flower class have a copy of a settings object passed in on construction?
The constant is an issue. If you had a property in the parent for color then it should pick it up. The subclass will set the property (thus overriding the parent). The possibility also exists for an event to come into play but that might be overkill.
It’s an intriguing question. I would think that it would be fairly simple to test in a very small project.
[quote=135119:@Stephen Dodd]How do you elegantly override a parent class’ settings and make use of them in inherited code? This isn’t particular to Xojo.
Let’s say I have a Canvas class with a long paint event. Call the class Flower. It has a colour constant used to paint the flower white.
I make a subclass called RedFlower. It overrides the colour constant to be red.
I don’t want to copy and paste the paint event. However, when my RedFlower calls paint, it used the parent’s paint event and also the parent’s white colour because the event is running in the parent.
How can the child use its own settings and elegantly use the parent’s paint event? (Assume there are many other settings/constants.)
Would it be better to use encapsulation and simply have a Flower class have a copy of a settings object passed in on construction?
Is there a more elegant design?[/quote]
In Xojo at best it shadows it
IF you want things to be overridable then you need something that provides that capability
In Xojo thats methods
So in your case your Parent has a PRIVATE constant of its own - kMyDefaultColor = &cFF0000
But its NOT accessed directly
You use a getter - DefaultColor() as Color
Then your subclass can override that with its own PRIVATE constant - kMyDefaultColor = &c0000FF
And it implements DefaultColor() as Color to return kMyDefaultColor
@Bob Keeney It is interesting, isn’t it? I can do OOP for years and still learn new stuff every week. BTW, looks like properties are treated the same as constants. The parent class always calls its own stuff.
@Norman Good workaround!
Pity that you end up with a bunch of getters. I wonder what kind of performance hit you get from a paint routine using getters instead of constants for a bunch of values.
If I’m going to use getters, I’m tempted to not subclass and just have the paint event reference an object thats loaded with all the settings.
BTW, what I’m actually doing is making custom ListBox rows. Each listbox row stores an object and references that object for the contents and to do various background and foreground paints. There are of course different kinds of rows. Now the listbox can easily custom paint itself.
That’s why I love doing the training videos on topics I’m not exceptionally conversant in. I learn something new every week.
I wouldn’t worry too much about this. We’re doing this in a number of placed in FTC (which is huge) and it doesn’t seem to affect anything. It’s not like you’ll be doing any calculations in the getters, it’s simply returning a value.
This sounds like the perfect time to use a protected property with a default colour set in the base class (parent), with the sub-class setting the property to a new colour value in the constructor.