Inheritance and overriding

[Eugen Graf]

Hello LAVAs!

I use LVOOP, but only as a nice Cluster. I have never use Inheritance and VIs for overriding before.

Also I develop a Web-Chat project, where I have Server and Client classes. Now I want to add a new Admin Client Class, which should be like the Client Class, but will have some additional features for Chat Administration.

1. Do I need to inherit the Admin Client Class from the Client Class ?

I use the Queued State Machine Design Pattern in my projects (Action Enum Typedef and Data as Variant). I want to add some additional actions for the Admin Client. So I need to create (just copy them from Client Class and edit the Items) a new Enum Typedef. I have e.g. a VI which waits on the next action (bottom while loop).

2. Should I create a VI for overriding for this Wait On Action VI to use them in my Admin Client Class, but with an othe Action Enum Output?

Thank You, eg

Edited July 22, 2009 by Eugen Graf

[crelf]

I use LVOOP, but only as a nice Cluster. I have never use Inheritance and VIs for overriding before.

That's a great way to get into OO - start using it as a super-cluster (with encapsulation, instantiation, etc) and then, once you're comfortable with that, move into inheritance. I've heard some ppl say that OO is nothing without inheritance, but that is so not true. That said, inheritance does make OO totally rock!

Also I develop a Web-Chat project, where I have Server and Client classes. Now I want to add a new Admin Client Class, which should be like the Client Class, but will have some additional features for Chat Administration. Do I need to inherit the Admin Client Class from the Client Class ?

From what you've explained, I'd say yes. The admin client class is just like the client class, but has some different functions, so you want to override the parent class (client) with the child class (admin client) methods (VIs). Of course, you only need to write the admin client class methods that need to override the client class methods - LVOOP will use the child methods as first priority, but if they don't exist, they will traverse up the class tree to the next parent class and use that method instead. If the method doesn't exist in that class, it'll go up another level, and keep on going until it finds one that does exist, and use that. It's quite elegant, and delicious to see it all work

[Eugen Graf]

Hello crelf!

Thank you for answer. I understand it theoretically, but can't implement it in practice.

The problem is the Enum-Output. In the Client Class the Wait On Action VI outputs a Client Action, but in the Admin Client Class it should output the Admin Client Action. The are two Enum Typedefs. Should I replace the output to a numeric and typecast them in the outer VI to the accordant Enum? Or I can solve this problem using overriding?

Regards, eg

P.S. if it should help to understand my problem I attached the whole project. This project is open source, I will upload them into LAVA CR later, if it works.

So please Open the Chat Project and look on the Server And Client Classes. There are two VIs Client.vi and Server.vi . The Server.vi should be started first, than the Client.vi

Thank you

Chat (2).zip

Edited July 22, 2009 by Eugen Graf

[PaulL]

Eugen,

You asked, "Should I create a VI for overriding for this Wait On Action VI to use them in my Admin Client Class, but with an othe Action Enum Output?"

In a word, yes!

You are moving in the direction of implementing the Command Pattern. The Gang of Four Design Patterns Book and other sources cover this well and I highly recommend taking a look at these sources. The Command Pattern is straightforward to implement in LabVIEW and is quite helpful. We use it in our project successfully, even over a network.

One note. You are concerned about not having the outputs of your override VIs match. To get around this (and for other design reasons) if you need to output something put the data you need into an object defined in a common class or in the class on the dynamic terminals. (Explore the concept of composition. This is extremely powerful.)

Paul

[PaulL]

Eugen,

The other thing I would recommend is that the dynamic VIs (the command handlers) would delegate the tasks to the model (which is a separate class). Then the dynamic VIs wouldn't have any partial model outputs. (It might have the model itself as an input and output.) Keep the Model-View-Controller separation principle in mind.

Paul