LVOOP: Custom class indicator

[MarcoMauri]

Hi!

Imagine to have three Classes:

Parent Class

Child Class 1

Child Class 2

Parent class has a method called "Read status", and each child class has its own version of the method overriding the parent one.

Basically the problem is that, for instance, "Child Class 2" has some status bits that are quite useful but that Child Class 1 has not.

So I would like to a have a customizable status indicator.

It is possible for the "Read Status" method to return a different status cluster for each Child Class?

Is there anything like an indicator similar to a custom probe, changing its appearence according to the class needing to be visualized?

Thanks in advance for your help,

Marco

[Norbert_B]

Marco,

if you refer to the output of the dynamic dispatch VI "Read Status": No, there is no way to have a different output datatype. Polymorphism of the inputs/outputs of dynamic dispatch methods is not possible except the class itself. Which means, you can use a generic datatype like string or variant for instance as possible workaround.

If you refer to something like "probe on the wire", you can use a custom probe or create an XControl to display the additional information.

Norbert

[Intaris]

The only way to do this would be to actually have a class as an output type.  This then raises plenty of other questions regarding accessing the data within or displaying the data which are not trivial to solve.

I HAVE done things like this in the past but it's cumbersome at best.

Shane.

[PiDi]

---

Basically the problem is that, for instance, "Child Class 2" has some status bits that are quite useful but that Child Class 1 has not.

---

Sounds like violation of Liskov Substitution Principle (ref: http://www.oodesign.com/liskov-s-substitution-principle.html). You have Parent which define "Read status" method, which return some kind of "status". Then both of the child classes re-define this "status" by returning something with different meaning. Without knowing exactly which class you currently have at the wire, there is no way to determine the meaning of this "status". This might be a clue to re-think the hierarchy design.

On the other hand, if those classes really belong in the same hierarchy, you could also make Status a class itself. Then you can derive parallel classes hierarchy, like:

This way you at least decouple the main hierarchy of classes from "statuses", and the visualisation part of your program have only to know about those "statuses", not about your main classes. You'd still have to cast Status class to one of the childs to obtain the right data (thats why there is GetKind method), but this way you might get a bit cleaner design - all the mess regarding status casting/changing would be left in Status hierarchy, leaving your main classes unchanged.

Ed. note: second part of this post is of course the extension to Intaris suggestion, but I don't necessary find it "cumbersome". There is always a part of the application which "have to know more", especially when it comes to visualizing data. By returning a class object, you're gaining clear definition of ReadStaus, and putting weight of defining each specific status on entirely different class hierarchy. You can then develop Statuses (for example add ToString method) without touching your main hierarchy. 

[mikeporter]

I like it -- a nice way of thinking about the problem. But your link is two characters too long: http://www.oodesign.com/liskov-s-substitution-principle.html.

Mike...

[PiDi]

This nasty auto-formatting of links 😉 Thanks Mike.

[MarcoMauri]

Thanks for your comments and suggestions,

it's nice to have someone out there dealing with the same problems 😉

[Intaris]

By cumbersome I mean the displaying of the information returned from the object method.

The OP wanted also to display the data.  This function then needs to be delegated to the status object in order to guarantee correct display and interaction which opens a whole other can of worms (sub-panels etc.).  We then have "active objects".

Don't get me wrong, I find the method tremendously powerful but it can be ahrder to visualise and tricky to code right if you don't have a proper software engineering background (which I don't).

Shane.

[mikeporter]

Done correctly, subpanels can be a very effective way to dynamically build a front panels, and really all objects are active in that they do things -- so displaying itself, or printing itself, or publishing itself on the web are just other things that it can do.
In terms of the software engineering background you think you need, if you are trained (or experienced) in a hard engineering discipline, you have all the background you need. You just need to learn to apply what you already know.
You really need to come to NI Week, I'm going to be talking about this very topic at length.

Mike...

[MarcoMauri]

For the specific case I proposed here, one could think about using a general data type, as suggested by Norbert.

For instance the "Read Status" output could be an array of key-value pairs.

As for the use of subpanels: it's very interesting and I'll try to implement it as soon as I have some time.

Regards,

Marco