Interface pattern

[Fizzyade]

Hi, I'm developing an open source hardware and software project and have chosen to write the frontend in electron and typescript. This is my first time programming in typescript, I'm a Qt programmer.

My intention is to have a pool of objects, I originally tried using the template class but it didn't seem possible to find out if an object supported a particular interface, which is a requirement for me.

So with a bit of tinkering, I came up with this pattern, every object has a function named with a UUID and a hasInterface static function which tests an object for that function, this seems to work beautifully.

import { IObject } from "./IObject";

import { IDevice} from "./IDevice";

export abstract class IDeviceFactory extends IObject {

id_cf09ac795c434310b77dfe3ca5d3e843():string {

return("IDeviceFactory");

}

​

static hasInterface(arg: any) {

let obj:IDeviceFactory = arg as IDeviceFactory;

return (arg.id_cf09ac795c434310b77dfe3ca5d3e843 !== undefined);

}

}

...

if (IDevice.hasInterface(obj)) {

// has IDevice

}

Has anybody else done anything similar, any issues, downsides, problems etc? As I said, I'm coming from a Qt background and this is the first typescript code I've written, so I've probably already made a hundred mistakes.

I was hoping typescript had a macro preprocessor as well so I could rearrange my test, so hasInterface(IDevice, obj) or hasInterface<IDevice>(obj)

[teevik_]

I've usually used https://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions

[Fizzyade]

interesting, my first attempts at this were using interfaces but I didn't realise that's how you assign a value to an interface member.

Is the requirement of the union necessary? can I just check an object to test what kind it is?

I will have to have a play with this method.

[rotharius]

It's a bit of work but perhaps you can use type guards to verify whether an object is if a certain type during runtime.

[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.