Q Re: OOA/D please critique structure

[LAVA 1.0 Content]

Should I break out controls and indicators as unique child-classes under Boolean?

I have the following class hiarchy.

Brief explanation;

Plug-ins - This class defines all objects I will be able to drop on the FP while the app is running.

Dynamic - All objects that will change while the app is in Operate mode. These will be controls and indicators.

Static - These will be background decorations and anything that has an image that does not change.

Boolean - All dynamic objects whos value is either 1 or 0.

LED - A round LED.

Toggle PB - Round push-button

Toggle SW - A toggle switch.

Since the LED class will not be something the user can click on (I'm trying to simualte the real world not re-write LV) it will not have to support a "Mouse Down" method. The "Toogle PB" and the Toogle SW" will have to support a Mouse Down method.

Does this observation indicate I should create two intermediate classes under Boolean "Control" and Indicator?

Let your comments fly, I am trying to learn with this project so your comments and suggestions are welcome!

Ben

[Yair]

Off the top of my head:

Add a style property (control\indicator, enabled\disabled, etc.) to the dynamic class (or even the plug-ins class, if you want to have the option for the future). Then, in the init method for that class, do the registering based on the style. Since your styles are currently constant, you can set the property in the init VI for each class and then call the parent implementation to do the registering. You can also add VIs for changing that property which will also register\unregister the event.

In general, for something like this, you might wish to look at how its implemented in LabVIEW itself, because presumably NI put some thought into it.

[LAVA 1.0 Content]

Like I said still learning.

I chose this project to learn LVOOP since it has many elements with which I (we) are very familiar, so I don't have to beat on the customer to worm out the design details since I drop controls all of the time. But I don't want to copy NI's approach exactly since that would turn the project into a transcription exercise. I would like to learn more about "why" in addition to the vocabulary and techniques. I also appreciate you sharing your thoughts because it helps me a lot! I'll try hard to avoid getting into one of those "well I know a req that I did not tell you" things. So the following is not a rebuttle to your comments but rather an attempt to use proper LVOOP terminology to share my thoughts on what you said.

QUOTE (Yair @ Jul 3 2008, 08:44 AM)

Off the top of my head:

Add a style property (control\indicator, enabled\disabled, etc.) ...

I understand a property of an object to be an element in the cluster that defines the class of that object. Since that property would determine the objects behaviour (methods?) it seemed that LVOOP's over-ride capabilities would be good fit.

Listening to what I just wrote...

So it seems I should modify my structure. I think I have to add two children to Boolean, Control and Indicator. I could then make LED a child of Indicator and set the Toggle PB and Toggle SW classes to inherit from Control. I think this would improve my architecture because I could implement the Mouse Down methods in the Control class since in the real world clicking on a LED does not make any sense (believe me I tried it and ended up breaking out a soldering iron to get it change states )

So after that...

All objects that are of class Indicator or children of such will have their "Control?" property set true and vise versa for Indicator. So the class implies the value of that property so what good does it do me? Not trying to fight over this Q just trying to learn which hammer (Class vs property) to use when designing an app. :thumbup:

QUOTE (Yair @ Jul 3 2008, 08:44 AM)

...

to the dynamic class (or even the plug-ins class, if you want to have the option for the future)...

OK, now invoking previously unknown spec...

The objective of this app is to emulate real world devices. This means that only those widgets at the bottom of the tree can be used by the app. So does implementing the idea of control/indicator get applied at the top of the architecture like it does in LV or is this an application requirement that dicates it should be handled at a lower level?

QUOTE (Yair @ Jul 3 2008, 08:44 AM)

...

Then, in the init method for that class, do the registering based on the style. Since your styles are currently constant, you can set the property in the init VI for each class...

Your term "init method" got me thinking since I'm initializing my objects in two different ways. In the first case I create a new object of every class that is a child of the class Plug-ins and use methods to determine which objects the user can drop in a panel layout. Once this is done I only use the class as a prototype from which the object that will be placed in the layout are created. Since I stumbled into this structure through the backdoor, I just used the "Create New" method like an init method. I should implelemnt an init mthod.

QUOTE (Yair @ Jul 3 2008, 08:44 AM)

...

then call the parent implementation to do the

registering

. ...

I think a light buld just went on. My first dozen reads of your response had me thinking that registering was just a synonym for "invoke mtehod". Then when trying to dismiss the possibility you were talking about registering an event it hit me that when I create the object, I could have it spawn off a background process that registers events for the picture control used to house the objects on the GUI. This one word alone may help me get rid of the one AE I am using to direct mouse clicks to the correct objects. So rather than filter the event and invoke a method from the GUI, I could let each background process filter if the event (Mouse Down, Mouse Move, Mouse Leave, ...) applies to itself. I WILL be giving this much more thought.

Thanks!

Ben

[Yair]

Again, I'm sort of writing as I'm thinking, and I'm not exactly an LVOOP user myself, but here goes:

QUOTE (neB @ Jul 3 2008, 05:16 PM)

I understand a property of an object to be an element in the cluster that defines the class of that object. Since that property would determine the objects behaviour (methods?) it seemed that LVOOP's over-ride capabilities would be good fit.

The property is indeed an element in the class cluster, and the overriding does play into it - if memory serves, you can have an override and then use the call parent implementation node (or whatever it's called) to perform the code of the parent class as well as that of the child class. This should allow you to move the code which is common to all classes into the higher classes and thus not have to reimplement with every class you create. Since I saw it, I assume there's an example showing this, but I may have seen it elsewhere.

QUOTE

I think I have to add two children to Boolean, Control and Indicator

....

All objects that are of class Indicator or children of such will have their "Control?" property set true and vise versa for Indicator. So the class implies the value of that property so what good does it do me? Not trying to fight over this Q just trying to learn which hammer (Class vs property) to use when designing an app. :thumbup:

As you said, the class implies the property in this case, so you shouldn't use the class. Since the only difference between controls and indicators is whether they can be clicked or not, the only thing you have to do for indicators is not register for the mouse down event. That's really easy and doesn't require a whole class, just a property.

As I mentioned, the property and the registering code should be in the high level classes (plug-ins or dynamic), so that they are shared by all inheriting classes.

Since the value of the property is constant for each class, you can just set it in code when creating the object of that class. I think that to do that you need to call the parent version of the init VI, which will eventually accept that constant. If that parent is removed by several layers, this may be an issue.

QUOTE

So does implementing the idea of control/indicator get applied at the top of the architecture like it does in

LV

or is this an application requirement that dicates it should be handled at a lower level?

Again, I would say that the object oriented paradigm says that you should implement functionality shared by all sibling classes in the parent class as much as possible, but I'm not really an OOP programmer.

QUOTE

Your term "init method" got me thinking since I'm initializing my objects in two different ways.

That term is not exactly technical. I suppose this should be refered to as a constructor VI, but LVOOP doesn't really have constructors. In any case, the bottom line is the same - objects should only be created by using those VIs, and the VIs should make sure that the objects are created with valid values.

QUOTE

I think a light buld just went on. My first dozen reads of your response had me thinking that registering was just a synonym for "invoke mtehod". Then when trying to dismiss the possibility you were talking about registering an event it hit me that when I create the object, I could have it spawn off a background process that registers events for the picture control used to house the objects on the GUI. This one word alone may help me get rid of the one AE I am using to direct mouse clicks to the correct objects. So rather than filter the event and invoke a method from the GUI, I could let each background process filter if the event (Mouse Down, Mouse Move, Mouse Leave, ...) applies to itself. I WILL be giving this much more thought.

I was actually refering to registering for mouse down events, and I'm not sure, but I think having a single point for registering those events (as I believe you've posted recently) is actually better. The registering will tell the AE (or whatever) the position, shape (possibly a hierarchy of classes as well) and Z-order of the object and the process will be responsible for finding the object which was clicked on (since it has the info of all objects) and sending the click to the object if it is valid. Of course, maybe the other method is better, but I don't like the idea of multiple event structures when one should be enough.

[LAVA 1.0 Content]

Thanks you!

Ben

[Yair]

Let us know what you end up doing (sample code helps :thumbup: ). I'm sure we could learn from the experience.

[LAVA 1.0 Content]

QUOTE (Yair @ Jul 5 2008, 02:13 PM)

Let us know what you end up doing (sample code helps :thumbup: ). I'm sure we could learn from the experience.

As you know I can't post usable code. But it just so happens that the code I have now will be re-written has bugs and generally... sucks. Besides, I have not added the Killer Rabbit object yet, so what good is it.

So see attached.

Demo VI is "Drop_Generic"

These notes show you what the controls do.

http://lavag.org/old_files/monthly_07_2008/post-29-1215362777.png' target="_blank">

A Index of element on screen. This is as dropped order.

B Stop demo

C Toggle between edit and operate mode

D Ring lets you select object to drop

E load from file. some objects do not operate after re-loading

F Save design to file

G value that will be written to the object at index (A)

H Read the selected objects value

I Write the selected object

J value read from object

K File spec of bmp file that serves as background. You must set this before running demo. I included some samples under "Graphic_Operations/Background_Images"

If you happen figure out why two of my three booleans do not work after re-load I would not mind at all.

Have fun,

Ben

[Yair]

I didn't really look at all the details, but it looks very nice.

One important UI tip from my own experience - when you drop an object, make sure the cursor is at its center, not its top-left corner. Additionally, you might wish to have an outline or a ghost image of the object when you move it. You can see both if you look at how you drop things in LV itself.