Occasionally, I see a video recommendation or stumble on a blog post about inheritance in programming. For those who don’t know, object-oriented programming languages usually allow an object to be defined as a “child” of another object. For example, you could define a “vehicle” object and then create children such as “car,” “truck,” “motorcycle,” or maybe “scooter.” You could even define children of those. Another common hierarchy is to define “employee” and then children, such as “manager” and “worker.” I think that now some programmers are recommending against this type of programming. I don’t know for sure because I ignore the videos and posts – I work daily with code with a lot of inheritance, and I don’t have the time, energy, or ability to jump on a new bandwagon. Plus, I like programming this way.
There are advantages to using hierarchies of objects. The Linkage app code defines an “element” object with all the shared properties of links, connectors, and splines. Those other objects are derived from the element object. This allows me to create arrays of elements without worrying about which types of elements are in that array.
So now I have reached the issue I wanted to talk about. I want a function in my code that returns the “thing” clicked on in the mechanism. The problem is that I cannot define a base object (sort of a root or oldest parent) with any useful properties. A link, for instance, has no coordinates, making it improper to define a base object with coordinates. On the other hand, a control knob for adjusting the control points of a spline has no name, color, or other properties common to links and connectors. If I created a base object type, I would have an object with no properties.
In the Swift language, I have a mouse click function that returns a temporary object containing an element and a control knob. Only one of those is ever valid, and the rest of the code acts differently depending on what is clicked. But maybe I’m doing this wrong since a link has no coordinates but shares properties with a connector. Maybe the fact that something is selectable and can be moved with the mouse makes them common. So maybe it’s the ability to move, rotate, scale, control knobs and links that make them similar. Should my base class be named “adjustable”? I might try that and see if it works. One aspect of control knobs that make them even more unique is that they have an element that owns them.
All of this is tricky. At work, I usually just do what’s easiest and quickest to get the job done unless there is a compelling need to design things perfectly. However, with the Linkage code, I can explore these design decisions and find out if I can reduce the amount of code I need to write by being clever with hierarchies and other aspects of the programming language.