Abstract Classes and Methods

[BrianGShea@NGC]

Hi All,

I've been working with G# for a few months now. Mostly to understand if and how this can be useful for the company i work for. I've been struggling to find a good use case for Abstract Classes and Methods.

I admit that I may not fully understand the concept from LabVIEW's or G#'s point of view, so please be nice. I want to learn and contribute, because I really like G# and hope it becomes the defacto standard for LabVIEW OOP.

So here's where I am at.

1) An Abstract Method MUST be overridden, however, an Abstract Method does not have to be Dynamic Dispatch enabled. This can create confusion because if the Method is Abstract and NOT Dynamic Dispatch, it cannot be overridden. Maybe this is an oversight in the Create Method Dialog? If not can someone please explain?

2) What is the use case of an Abstract Class? I can create an abstract class in my project and can use it just like a normal class, i can create child class from it and so on. If the Class is abstract, should it not only define the Methods and Properties that the implementing classes needs to have? All of which will throw an error on use? Shouldn't an abstract just be an empty shell that defines methods and properties, that gets duplicated by a real class? Maybe this is a limitation of LabVIEW?

From what I understand of other OOP languages an Abstract class cannot be instantiated and used as if it were a real class. This would result in a compile error. Obviously in LabVIEW we cannot create a compile error, but if the Create method is called we can return an error?

It would be AWESOME if an Abstract class was created with Methods and Properties then any child class created from the Abstract class would have all methods and properties added into it, including class attributes. However, the create method would not call the parent's create method, because the abstract class cannot really be instantiated, i.e. it is not a real class, just an empty shell.

3) There are no examples of how Abstract Classes were intended to be use in the G# examples. Does someone have an example use of Abstract Classes. Maybe I missed it?

4) Is it really valid to have an Abstract Method be part on a non-Abstract Class?

Like I said, I'm new to G# and my be missing some key information!

Thanks,

Brian

[Yamaeda]

funciton1) Cant help you there. 😕

2) An abstract class/function is in reality an empty shell in that you'll get error if you haven't implemented a true class/function. I'd say it's a limitation of LV, but on the upside you can use a class without all functions defined if you dont use them ...

Dont cloned/inherited classes get all methods? (dont have G# here)

3) At work we have testobjects, called UUTs. We have a common base class with basically all interface methods as abstract, as each UUT-type must implement them. Since the cpu-controller is quite different there's no use of implementing these functions in the base class, but each cpu-type needs to handle it themselves. Thus Abstract in the base class.

4) Yes. Classic example would be the Vehicle example. Any Vehicle would have Driver and Get/Set driver as true methods, whereas Drive() would be abstract as it requires Motorcycle, Car or some other inherited class to implement them.

/Y

[Yamaeda]

Interesting, the forum complained about "Problems posting your message" but after 2 tries i had 3 posts ...

/Y

[griffindore]

Hi Brian,

Mike Lyons from NI here (I'm not one of the AddQ guys so this is purely my experiences and not an official response).

1) AddQ will have to comment specifically for the setting of Dynamic Dispatch. You can always change the settings yourself though to break what G# is doing for you. Really what they're allowing is the ability to have things like an abstract method. So if the developer creates it properly by setting it to dynamic dispatch, you at least get the capability of an abstract method. From what I've seen, the only thing that G# adds for an abstract method is a subVI that generates an error if the method gets called. LabVIEW has the ability to force children to override which also tries to accomplish the same thing. I often use "call parent" but still want 'abstract method' capability in some cases, so when doing this, I've gone in and placed the subVI that generates the error in a case structure. Since G# has a subVI "Is Call to Parent?", I use that to see if a child called the method or whether it was actually an unimplemented abstract method. Someone might comment on whether I'm doing things in a good OOP design practices or not, but it worked good for me.

2) Yes for the most part your abstract class methods should just be an empty shell. Again, I may be breaking good OOP design practices, but I've found it useful to make Abstract Classes that have non-Abstract Methods. Really what makes a class abstract is that you can't call the constructor meaning that you can never instantiate that class. But if I need some base functionality that I know will be shared by child classes, why force them all to implement the method, so in some cases I've been creating non-Abstract Methods as part of an Abstract Class.

As you stated, the Abstract Class cannot be instantiated. This is something really cool that G# imposes. In LVOOP, by default there is no constructor and an object is created through the object constant. G# forces constructor and destructor methods. They do this by making the object data a DVR. So if you use the object constant, you get a useless data wire that contains a DVR reference that hasn't been initialized. The only way to actually create the object by creating the DVR is to call the constructor. So to make an abstract class, G# makes the constructor protected (so that a child class can still call the parent constructor) so that an object of the class can never be instantiated. The class can however still have static methods I think. I think this verifies what you think would be AWESOME, but let me know if it isn't.

3) Maybe I can send you the VeriStand clases I've been using. I'll have to post this after NI Week though.

AddQ, please correct any mistakes I may have made and weigh in on your opinions.

Regards,

Mike Lyons

[Fox_Mccloud]

Hi Guys!

Great discussion! Wonderful to see OOP-programmers discussing G# implementation!

I will try to keep AddQ answer short and concise since Yameda and Mike has allready filled most of the gaps. Thanks!

You are absolutly right Brian. Abstract classes should not be able to be instantiated and only have unimplemented class methods and public data. We enforce the disabiltiy to instantiate abstract class objects by making the constructor of the abstract class protected, as Mike pointed out. How ever, I just compiled a small example for you and to my disgust noticed that upon creating a abstract class from "new >> G# Class" did not set the constructor to protected. We will fix this in the comming release in late august. For now, select your abstract class in the project explorer and choose "G# Ide >> Change Abstract" once to make it a non abstract and then once again to make it abstract. This will make the constructor protected.

To force implemented of methods in the implementation class we usually use the Error If Missing Method vi found at: "..\National Instruments\LabVIEW 20XX\vi.lib\addons\_AddQ\G#Object\protected\G#Object_ErrorMissingMethod.vi". This will give a error at runtime if implementation class misses methods defined in abstract class.

Error Missing Method Implementation

There are ways to make LabView force implementation on methods but when we tried this the project enviroment reported errors in virtually any class that aggregated or inherited from a abstract class that had a implementation class with unimplmented methods. It just was not very practical. Another reson is, as stated above, it gives the posibility to have some implementation in the abstract class. This breaks some of the OOP rules I guess. How ever, I don't think you will be thrown in jail for bending the OOP practices.  Keep it as simple as posible, but never simpler than that.

If you have implemented methods in your abstract class and want to generate these in your implementation class you can use the override method function in the create new method dialog.

Create a new method in your implementation class. When the Create Method dialog is shown press "Override Method". In the Override Methods list box all methods available in abstract class will be shown. As the method is created the subvi control interfaces will be auto generated.

Overriding methods from abstract class

I have compiled a small example of the thing we mention above and attached it. Please reply if I have missed anything.

Sincerly,

Andreas Beckman

AddQ

[BrianGShea@NGC]

Fox

The Protected Constructor missing  by default on Abstract Classes now makes sense! That was a solution I had used to enforce the class not being instantiated by the user outside of the child class in my example.

I did more investigation of the Abstract Classes and Abstract Methods here is what I found (and if there is a better way to make these work please let me know)

1. If your Abstract Class has a property, only the parent can access it via the Get Attributes, all others must use the Get/Set or Property Nodes.
2. There are no Abstract Properties? Parent must implement all common properties, or the programmer(s) must have restraint to implement all common properties that may have slight differences. I.e. Bounds checking on the property value.
3. If your Abstract Class has a non-overridden Abstract Methods with default functionality it cannot access the child’s properties unless the child object is passed in via a separate Object Reference. I think this is the same as other OOP’s but it’s been a few years since I’ve done any real OOP in C++, C# or PHP. But for some reason I have a nagging feeling that the Abstract Method code runs in the same namespace as the inheriting class (the child class). Maybe, maybe not!

Other than that I think it all makes sense how Abstract Classes where intended to be used. The Constructor should be made Protected but the developer (until the next release).

‘There are ways to make LabView force implementation on methods but when we tried this the project enviroment reported errors in virtually any class that aggregated or inherited from a abstract class that had a implementation class with unimplmented methods. It just was not very practical. Another reson is, as stated above, it gives the posibility to have some implementation in the abstract class. This breaks some of the OOP rules I guess. How ever, I don't think you will be thrown in jail for bending the OOP practices.  Keep it as simple as posible, but never simpler than that. ;)’

Abstract Classes can provide methods that have default behavior so allowing G# to provide the same behavior does not break OOP rules (or at least rules that have already been broken by other OOP languages )

Fox, one last thing: What about creating an Abstract Method without Dynamic Dispatch? I would think that the Dynamic Dispatch checkbox should be checked and disabled when an Abstract Method is selected when creating a new Method for the Abstract Class.

Can’t wait for the next release!

--Brian

[Fox_Mccloud]

Hi Brian!

Splendid that you came to a conclusion! 😃

About disableing the dynamic dispatch on a abstract method. This would make it non viritual and not possible to override. If you want the method to be a abstract method with a none overridable implementation you could uncheck the dynamic dispatch. This is probably not the case in most abstract methods, so I belive the checker box in "Create new method" window should be checked as default.

Is this what you ment or would you care to elaborate a bit more?

Are you going to NI Week? If you want to have a chat we will have a few of our guys over there who can answer questions in person.

Sincerly,

Andreas Beckman

AddQ

[BrianGShea@NGC]

I guess my thought was if the method is abstract it must be overriden. In labvew we cannot create a method with only a front panel for In's and Out's so we must provide by default an error on the error out to provide the developer (and hopfully not the end user) some indication that some functionality is missing.

As you stated in a previous post, creating the method broken cause all other methods in the class and subclasses to be broken.

If the Abstract Class provide a method with default functionality, then it would not use an abstract method and may or may not enable dynamic dispatch.

Anyway, i'm glad we had this discussion! If i can make it to NI Week this year I will stop by and talk to you and the other G# developers. NTS will usually send 2 to 3 representitives to NI Week so it's a hit or miss for me.

Thanks

Brian

[Mattias_Ericsson]

Hi Brian,

Sorry for the late response but I've been on vacation until now. The idea with G# is to make it behave as much as possible as C# would do. When developing the G# functionallity, we just have a look of how C# behaves.

Abstract class - this class must always be inherited, but could contain abstract methods (methods without a body) and non-abstract methods (that could be declared virtual or non-virtual) and thereby provide a default implementation if the method is not overridden in a subclass.

Abstract method - this just provides the method signature (VI connector pane) and must be overridden in a subclass. If a class contains an abstract method, the class must also be declare abstract in C# (not the case in G# for the moment).

If a class is declared abstract and only contains abstract methods it would be more common i C# to declare it as an interface instead of an abstract class. The difference is that a class could inherit multiple interfaces, but only one class (abstract or not).

So how does G# implement this? To prevent an abstract class to be created directly and only be used as parent class, the contructor is set as protected scope and the class gets a different icon overlay symbol. This will cause a compiler error if you try to use the "Create" method directly. In the create method and create class dialogs, all the above rules are currently not checked, like there is no check if you use an abstract method template in a non-abstract class. We could of course implement this, but we have choosen to be a bit "forgiving" if you don't follow the "C#" rules. It did simplified the implementation of the G# IDE, but we have it on our ToDo list. This is what we probably will implement in the future:

* Force dynamic dispatch on the "Abstract" method template (as you mension it doesn't make sense else). Next release.

* If the class isn't abstract, the "Abstract" method template shouldn't be selectable.

Please notice that in the G# options (Tools -> G# IDE -> Options), there is an option called "Require descent classes to override dynamic dispatch VI", this is by default set to false, but if you mark this, all dynamic dispatch VIs are required to be overridden, else LabVIEW will return a compile error. The reason why this is set to false by default, is that many G# users alway set dynamic dispatch in case the method needs to be overridden. It has also been some project environment problems with a lot of non-executable code if there isn't a subclass loaded in memory that implements the methods (this might however be fixed in last version of LabVIEW). You could of course alway just right-click on the class in project environment and then just set the LabVIEW class properties directly as you wish.

Thanks,

Mattias