Jump to content

CLD sample exam organized using LabVIEW classes


Recommended Posts

Hi Aristos Queue,

First of all, thank you for posting your solution. At last we can see some simple examples of LVOOP.

There are two things I would have done differently, one major the other minor:

1. The (action wrapper VI) would be a method of the "ATM.lvclass".

The "ATM Massage.lvclass" would only be used for transfering the massage, not for doing the action. The massage would contain typedef enum named "Action" as private data. see here.

Inside the case structure I would put dynamic dispatch VIs for handling the actions, so ATMs that will inherit from a more generic ATM would override these actions if needed. The massages will remain the same for all ATMs.

So, my point here is: The action should done by the ATM not by the Massage.

2. I would make the massage event data type a typedef enum. It will be more strict and readable then free text.

Regards,

Amir Y.

Edited by Amir_Y
Link to comment

Two things here:

1. Strictly thinking you are right about eliminating enums and case structures, but in my opinion, you should sometimes use them to improve readability and access. Enum is easy to read. Case structure is easy to access. When you open the action wrapper VI, you know which action you are looking for. Finding it in the case structure is much easier (and readable) than than double-clicking a dynamic dispatch VI which open a dialog where you have to look for the desired action.

2. "Do Core" VIs as part of the message seems a mix-up to me. The action should be done by dynamic dispatch methods of the ATM, so each inherited ATM could preform the action differently. Message object should only transfer the message (and it will be the same to all ATMs).

Amir.

Link to comment

Amir, remember the goal is to pass the exam, not create a well-designed application. I'm not saying AQ's submission isn't well-designed, but the design is secondary to the functionality. (Incidentally, this is exactly why I resisted so much in the other thread. It's impossible to justify a design based on a bad spec document.)

Finding it in the case structure is much easier (and readable) than than double-clicking a dynamic dispatch VI which open a dialog where you have to look for the desired action.

Personally I agree. However, people place different values on the various tradeoffs. AQ tends to favor code that is verifiably correct. He's willing to give up a bit of readability to achieve that. I can't see that either approach is objectively better than the other. They each have their pros and cons.

2. "Do Core" VIs as part of the message seems a mix-up to me. The action should be done by dynamic dispatch methods of the ATM, so each inherited ATM could preform the action differently. Message object should only transfer the message (and it will be the same to all ATMs).

What inherited ATM? The spec doesn't say anything about multiple types of ATMs. I agree it's a natural extension point an alert developer should discuss with the customer, but it's not in the spec and (presumably) isn't going to gain you any points.

(The spec does say "Be easily scalable to add more states / features without having to manually update the hierarchy." Unfortunately that's way too vague to be a helpful guideline when making detailed design decisions.)

Link to comment
  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.