Interfaces

[Daklu]

Welcome to the forum Stobber!

But doesn't that fundamentally change the behavior of the class wire on the client diagram? ... It seems like any client developer who uses these interfaceable classes will have to know that they don't behave like normal classes do on the diagram.

Absolutely. By-ref classes bring a different element into Labview programming. If users don't know a class is by-ref they can easily end up getting into a lot of trouble in their code. You can see from the methods for those two classes that I chose to use the same "bent corner" icon adornment that NI uses for their references (assuming the code I'm looking at is the same version as what is in the CR.) It's not a perfect solution, but it's works pretty well once you get used to it.

Interfaces work equally well with vanilla by-value classes. It just makes for somewhat less interesting demo code.

...downloaded the latest copy of the framework, got a teammate who really knows LVOOP to explain it to me...

He understood it? I'm always a bit shocked when anyone can make sense out of these things I throw out there.

...I suppose the alternative would be to wrap the class wire in a DVR and pass that around between methods, but then you lose dynamic dispatching and the whole thing kind of falls apart. I don't know the answer here, just thought I'd ask the question to make sure my understanding is correct.

Last summer when DVRs were first released there was a lot of discussion on whether the DVR should be internal or external to the class. I think most people primarily use them internally now, but there isn't really a right answer. If I have a class that sometimes needs by-val instances and sometimes needs by-ref instances, then I create the class itself as by-val and put it in a DVR when necessary. If the class always needs by-ref data then I use a private DVR to define the class as by-ref.

This looks like a very cool workaround for interfaces, and I'd like to start using it in my projects if I can.

You are more than welcome to if you want. Let me know how it goes. Right about the time I released the initial version I discovered that I didn't need Interfaces to solve the problem I had created them for. Implementing a HAL was a better solution for me. In fact, I have yet to run across a situation where I have needed Interfaces. I think they can be useful, especially in creating and using certain reusable LVOOP frameworks, but in application code I haven't needed it.

-- and forgive me for using my inaugural post to challenge a revered poster --

Heh, I haven't been revered since my teenage daughter graduated from diapers.

Truthfully, I'm nowhere near the most knowledgable programmer that posts to Lava. I have far less LV experience than most and like you I don't have the CS background of a traditional programmer. (I was a Mech Eng in my previous life.) One thing I do have going for me is I'm not afraid of looking foolish, so I'll post whatever wacky idea or failed experiment is on my mind at the moment.

So while I'm always happy to learn I've created something useful for others, please save the reverence for someone more deserving. I'd much rather have others critique my code/ideas and look for improvements than accept them as the "right" way to do something. I'm learning as I go along, just like everyone else. What I posted last year, last month, and possibly even last week may not be inline with my thinking today.

[Yair]

Heh, I haven't been revered since my teenage daughter graduated from diapers.

If your daughter had to wait until she was a teenager before being diaper free, you may want to have her (or yourself, more likely) checked out by a psychologist.

[MikaelH]

Hi Guys

FYI:

I’ve just implemented support for <<INTERFACE>> in GDS(GOOP Development Suite).

I’ve attached the code the tool creates.

Interface.zip

The tool automatically creates an extra class that redirects the Interface method calls to the Class that likes to implement an <<INTERFACE>>.

Cheers,

Mikael

[Daklu]

I’ve attached the code the tool creates.

Hey Mikael,

In general I prefer not using wizards when I develop code; however, implemeting interfaces can be tricky if one isn't used to it so I can probably make an exception for this.

I like that your implementation doesn't require a base Interfaceable class. That makes the framework somewhat less intrusive than mine. It does have the tradeoff in that you can't interate through a collection of objects that all implement the same interface--you have to get the interfaces from each object first and iterate through the interfaces. Does it matter? I dunno... I like the idea of being able to get an interface without knowing about the specific object (using Interfaceable:Get Interface), but to be honest I'm not sure there's a use case for it.

Unless I'm misunderstanding your code, I believe there are some flaws in your interface scheme with respect to how it handles by value classes:

1. As part of the class definition, ByValueClass contains 'I ByValueClassRef,' an instance of it's implemented interface, ByValueClass_MyInterface. You are initializing 'I ByValueClassRef' in the ByValueClass:Init method. This means ByValueClass is carrying around a copy of itself, potentially doubling your memory use. It also adds in the complication of forcing the class developer to implement code to keep the data in both copies synchronized. Why not ditch 'I ByValueClassRef' altogether and insert the copy of ByValueClass in ByValueClass_MyInterface as part of ByValueClass:GetI_MyInterface?

2. The interface object returned by ByValueClass:GetI_MyInterface is a copy of the ByValueClass object. It works okay in your example code because it is just showing a dialog box. What if the interface actually changes one of the object's values? The original object doesn't reflect the change. If I'm getting an interface to an object, I'm intuitively expecting the interface to operate on *that* object, not a copy of that object.

3. After using an interface to change the value of an object, there's no way to change the interface object back into the original object. This essentially makes all interfaces read-only operations.

-Dave

If your daughter had to wait until she was a teenager before being diaper free, you may want to have her (or yourself, more likely) checked out by a psychologist.

The funny thing is the night I posted that comment I actually dreamed she was still in diapers.

[MikaelH]

Unless I'm misunderstanding your code, I believe there are some flaws in your interface scheme with respect to how it handles by value classes:

You are absolute right, if you use by value it doesn’t behave as expected, I guess this design should only be used for reference classes.

//Mikael

[Daklu]

I guess this design should only be used for reference classes.

Or you could tweak it a bit and make it compatible with by-value classes.

I solved that problem by "casting" the object to an interface and then "casting" it back into the original object. You can certainly do that--your implementation would still be different enough from mine that it would benefit the community to have both and see which one is more useful. If you come up with an alternative solution I'd be really interested in seeing it.

[MikaelH]

Just to keep this thread a live, I'm uploading one of my interface solutions using variants.

This way is quite easy, but very slow.

Interface_Variant.zip

It's in LV2010

Cheers,

Mikael

[Stobber]

Hey Daklu,

I finally finished the SimUDuck program from the book. Writing classes in LV takes a lot of extra work: creating the byRef typedefs, making the class icon and wire style, setting inheritance....and having to do it twice for each "class pair" that makes up an interfaceable class...it really makes me consider whether having interfaces is worthwhile! I'm probably just lazy though. Got any tips to make me a more efficient LVOOP coder?

Anyway, here it is. Mind taking a look at it to see whether I did it right?

I wonder whether the Strategy pattern could be accomplished without needing interfaces. I know some patterns can be approximated without using classes, like using dynamic events for Observer.

simuduck_lv901.zip

Edited August 19, 2010 by Stobber

[Aristos Queue]

it really makes me consider whether having interfaces is worthwhile! I'm probably just lazy though. Got any tips to make me a more efficient LVOOP coder?

Once you get the pattern down, spend some time writing an automation tool using LV scripting to take care of some of that work for you.