Subclass

For this it would be great if RectControl (or it’s parent, the Control class) had a Tag property.

Here’s an example using composition from one of my current projects. I’d made a Canvas subclass, CanvasTouch, that does all the work and declares to add these OSX events: GestureRotate, GestureMagnify, TouchDown, TouchDrag and TouchUp. There’s quite a bit to set this up but in a subclass of CanvasTouch it just looks like a Canvas with those extra events.

Later on I wanted those same events in an OpenGLSurface. I can’t inherit between these two or from some common super, I’d have to either duplicate all the code in a OpenGLSurface subclass or repackage the functionality so it doesn’t have to come by way of inheritance.

Yes, at first I didn’t like the thought of having to write that extra code to tie functionality in, but as it became clear the only alternative is wholesale duplication of all that code it looked better.

The main downside to this approach is the compositing process, that code needed to tie it together. So as I designed this composable object the focus was on making that as effortless as possible. There’s still work to be done but it’s straightforward and minimal.

After refactoring I have an object subclass, TouchableView, with Structures, Constants and all kinds of stuff, and a Canvas and OpenGLSurface subclass each with a TouchableView property and a handful of mostly one liner methods. Also now if I want those touch events in a Listbox or Window it just takes a few minutes to compose in a TouchableView.

The object that’s being composed will most likely need to communicate back to what it’s a part of. In TouchableView this is done through a set of delegates received in it’s Constructor, but usually you’d just pass in a reference and call on it’s methods. That may seem like a bad idea because then those methods have to be public so the composed object can call them. Not so! Interfaces save the day :slight_smile:

Add the necessary callback methods to an interface and use that as the type in your composable object. In the class that implements the interface those methods can be marked Protected or Private yet the composable object can still call them through it’s reference because it’s the interface type which isn’t bothered by scope.

It may seem roundabout to implement composition but I find the determining factor the size of duplication it saves. TouchableView wraps up a lot of code compared to what it takes to compose it. If what you’re doing is so minimal that you’re not really wrapping anything then just duplicate it, you have to, there’s no multiple inheritance. You can always factor it so everything is at most 1 line.

The question is how to add something repeatedly with minimal effort and impact. There’s a variety of ways depending on exactly what that something is supposed to be. In other situations I’ve made code that autogenerates classes or one where I duplicate a template class and then search/replace a certain type. Maybe if we know more specifically the functionality you want to marry in then a better idea will come up.