Article Preview
Buy Now
FEATURE
The Subclass Reflex
Rethinking Inheritance in Your Xojo Projects
Issue: 24.2 (March/April 2026)
Author: Tim Dietrich
Author Bio: Tim uses Xojo to develop custom software for businesses that are running on NetSuite.
Article Description: No description available.
Article Length (in bytes): 14,347
Starting Page Number: 23
Article Number: 24203
Related Link(s): None
Excerpt of article text...
You're two levels deep in a class hierarchy when you realize the method you need to change lives in the base class. You make the fix. A subclass on the other side of the tree breaks. You patch that. Now a third subclass behaves differently than it used to.
If you've been writing Xojo code for any length of time, you've probably been here.
Why We Default to Subclassing
Subclassing is the first OOP concept most of us learn. The textbook pattern is simple and satisfying: you have a base class, you extend it, you get all the parent's behavior for free. Xojo makes this especially easy. Drag a control from the Library to the Navigator, and you've got a subclass. Set the Super property, and you're inheriting.
For UI controls, this instinct serves you well. A NumbersOnlyTextField that extends TextField makes perfect sense. It is a TextField - it just adds validation. A MonthPopup that extends PopupMenu works beautifully. The "is-a" relationship is genuine, and the framework is designed for exactly this kind of extension.
The problem starts when we apply the same reflex to everything else.
...End of Excerpt. Please purchase the magazine to read the full article.









