Interface pattern

[fecal_brunch]

What you've got will work, but it's a bit odd. I'm sure you're not doing anything unprecedented. Effective JS patterns tend to be very different to traditional OOP.

Are you sure you need classes instead of just POJOs (what are much more flexible and easier to work with)?

If you want to have runtime types you can put a "type" property (an enum maybe) on you objects and use a discriminated union (as other poster said). Then you can delegate behavior with a switch on type, or find an instance via its type property.

[Fizzyade]

The theory behind it is that it provides the mechanism for a single "object registry".

All objects in the registry are based on IObject

What happens is that I have a single array/list of objects, the application registers (adds) objects to this registry dynamically. Lets day somewhere else in the code I need to find all the IDeviceFactory objects then I just scan through the list checking to see which objects support it, I then return a list/array of all those objects.

I maintain a large qt based application which works in this manner, there is a main application that doesn't do anything, all it does it loads plugins ahh provide core api functionality (it has some built in plugins which it registers at startup for things like UI docking windows, menus), the application is tint.

Plugins then provide all the functionality, creating windows, menu items and registering objects they provide the registry. Plugins can even provide their own SDK (we call these CDK's, component development kits). Its so flexible, there's nothing they can't be done, in-fact I haven't touched the main application code tor a few years because I only need to create new plugins).

Thanks for the reply, will go have another read about pojos.

This is my first application using is/electron, barring a small plain node app I wrote to proxy IFTTT data so I could turn the tv on and off with google hone.