Jump to content

mgould2001

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by mgould2001

  1. Thanks for the commend, I have seen composition used before and I should have included it. So is that (Composition) the standard way of dealing with objects that have some things in common but something that are not? I'm just really curious because this seems to come up a lot in the couple years we've been using LabVIEW OOP, especially when you are developing HALs. For example lets say you have a power supply class. Most power supplies have a init, close, set voltage, set current, etc but occasionally you'll come across one that has additional (useful) functionality that the others don't have. If I want to make use of that additional functionality, do I start a whole new class hierarchy? If I do that then I've broken my power supply HAL. It seems like this should be solvable with OOP since its designed to EXTEND functionality of a class. BTW, bark and meow were bad examples. I should have used something like cats can claw and dogs can track. Two totally unrelated functions that you can't easily attribute to just any animal.
  2. Lets say I have a class hierarchy like this: NOTE: Stole this hierarchy from this thread because it was helpful in understanding my problem. The classes have functions that look like the below. The intent is that any animal can have a name but only dogs can bark and only cats can meow. There is also a "Find Animal" VI that takes an array of animals and finds the first object with the provided name. And I use it to write code that looks like this: Obviously after the find animal I have a broken wire because any animal can come out of the find animal and the compiler cant guarantee that the "Meow.vi" will work on every animal since it is a method of the felidae class. It is my understanding I have one of two choices at this point: A: I can add "Meow" and "Bark" as methods to the parent class, and make them dynamic dispatch. I've done this with projects in the past and everything works fine. The only problem is you end up with enormous parent classes that have tons of methods that don't do anything. It also "feels wrong" because I don't like the idea of having a ton of placeholder code. B: You do something like this: In this case you are guaranteeing the compiler that at run time there will be a specific class on that wire and that it can take it to the bank. If it turns out that the class on the wire is the wrong type, we give it an out with a error handling case. I'm a little uncomfortable with this type of code because I haven't done a lot of it, but I don't know how well it scales. My question to you all is, "Am I correct in my understanding or is there a better way to deal with this case?" Thanks, and I'll attach the proj to this thread. Animal House Example.zip
×
×
  • Create New...

Important Information

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