Friends Classes

[jgcode]

What are people doing with Friends Classes?

How do they fit into the LVOOP paradigm?

Edited August 16, 2009 by jgcode

[unicorn]

There are no "friends" in LVOOP. I think friend classes are workaround to reduce the need to access all class data via methods. In some case it makes programming easier. So in "classical" (non-OOP) programming everything was a friend from everything.

[jgcode]

There are no "friends" in LVOOP.

I don't understand. Are you able to elaborate please?

Cheers

[PaulL]

LabVIEW 2009 introduces a "friends" relationship. Essentially ClassA can declare ClassB (or another type of library, or even a VI) to be a friend. Then ClassB can call any methods ClassA sets as "community" scope.

NI has updated these pages with the details:

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

Creating LabVIEW Classes

Edited August 17, 2009 by Paul_at_Lowell

[unicorn]

@Paul: Right. I haven't looked into LV2009 yet.

@jgcode: A class which is declared as a friend can access private or protected attributes of the class where the declaration is. In contrast to public attributes only specific classes can access the class attributes. Accessing attributes directly improves performance. So if you rember that calling a VI allocates space for the input and output data it is clear that the performance is better with direct access than accessing data via methods. On the other hand data is not protected any more if its public. So friend classes are a compromise between the trade off protecting data of an object and improving performance.

[PaulL]

There are a couple interesting things here in LabVIEW.

First, LVOOP class data is always private. This was a (very good, I think) design decision NI made. It promotes the use of accessor methods, which OO designers generally consider a good idea. (For more on this, see An Introduction to Object-Oriented Programming, 3rd ed., Timothy Budd.)

Second, LabVIEW 2009 introduces the concept of "community" scope (in addition to public, protected, and private). LabVIEW is probably the first language to use such a scope! Setting the scope to community for a class method specifically adds it to the list of methods that a friend can access. (By the same token, methods with community scope are the only methods of the class that the friend(s) can access.)

[jgcode]

There are a couple interesting things here in LabVIEW.

First, LVOOP class data is always private. This was a (very good, I think) design decision NI made. It promotes the use of accessor methods, which OO designers generally consider a good idea. (For more on this, see An Introduction to Object-Oriented Programming, 3rd ed., Timothy Budd.)

Second, LabVIEW 2009 introduces the concept of "community" scope (in addition to public, protected, and private). LabVIEW is probably the first language to use such a scope! Setting the scope to community for a class method specifically adds it to the list of methods that a friend can access. (By the same token, methods with community scope are the only methods of the class that the friend(s) can access.)

Hi Paul

Thanks for the links to the updated documents above.

Do you have any examples of where this may be used in a design pattern?

I see that the community scope needs to have static inputs which is interesting.

[nhollenback]

One of the purposes behind "friends" is to tighten the relationship (pun intended) between XControls (a type of library) and LVOOP classes. So now there is greater protection in setting up an XControl as the UI for the class data. Prior to this, the XControl would have to access the class data through public VIs. As such any other VI could access the data through those public VIs.

Now, the class can declare the XControl as the friend. Thus there is protection of the class data for anything other than the XControl friend (or other descendants through protected methods).

Hope this helps.

[tkuiper]

Maybe I'm too much of a purist, but this idea of a 'community' scope sounds potentially dangerous. The precepts behind OO have been around for quite awhile and have been proven to be necessary and sufficient for valid design. Adding another "scope" to a language to suit an internal mechanism (or serve as a shortcut to such) seems like it will only - if left public - serve to muddy the waters. What then is the difference between community and private? Or community and public? What if community no longer serves the purpose and we need a semi-community scope? Does LV2009 release 2 add another scope (or, heaven forbid, change community scope) in order to correct a few unforeseen consequences? Where do the scope changes end?

Friend classes are, by nature, exceptions to the rule and I've never been fond of them. It seems like friend scoping is only present to facilitate lazy coding (purely removing the need to create accessors/mutator for another class' member data!) and, in much of the code I've had to work with, was a backdoor to trouble.

If access to private member data is necessary, why not script creation of the necessary accessors and mutators? (Major KUDOS to NI for developing and releasing scripting!)

Tony

[jgcode]

One of the purposes behind "friends" is to tighten the relationship (pun intended) between XControls (a type of library) and LVOOP classes. So now there is greater protection in setting up an XControl as the UI for the class data. Prior to this, the XControl would have to access the class data through public VIs. As such any other VI could access the data through those public VIs.

Now, the class can declare the XControl as the friend. Thus there is protection of the class data for anything other than the XControl friend (or other descendants through protected methods).

Hope this helps.

Cool - thanks for this, this is exactly what I am after

Kudos

Edited August 18, 2009 by jgcode

[unicorn]

One of the purposes behind "friends" is to tighten the relationship (pun intended) between XControls (a type of library) and LVOOP classes. So now there is greater protection in setting up an XControl as the UI for the class data. Prior to this, the XControl would have to access the class data through public VIs. As such any other VI could access the data through those public VIs.

Now, the class can declare the XControl as the friend. Thus there is protection of the class data for anything other than the XControl friend (or other descendants through protected methods).

Hope this helps.

It is good to have a UI for the class data. But this could have solved also by allowing XControls to become members of a class. With this concept the XControl is tightened to the class and has direct access to the class data. But it cannot be used without the class any more. So there is no need to have this XControl outside of the class.

[jgcode]

It is good to have a UI for the class data. But this could have solved also by allowing XControls to become members of a class. With this concept the XControl is tightened to the class and has direct access to the class data. But it cannot be used without the class any more. So there is no need to have this XControl outside of the class.

This is a great discussion

Was there a reason for (not doing) this?

(Off the top of my head) Is this related to / is there still a problem wrt LVOOP + XControls and infinite recursion??? - I remember AQ mentioned something in a post about a deep architectural barrier, and a problem but can't find the post.

Edited August 18, 2009 by jgcode

[Daklu]

What are people doing with Friends Classes?

How do they fit into the LVOOP paradigm?

I've been experimenting with friend classes as a way to limit the public interface of my code modules. For example, I created a set of classes in 8.6 to support Collections that I distribute in a single OGPB package.

The Variant Collection class is the only one I want exposed to package users. In 8.6 I have to wrap everything in an lvlib and set my supporting classes, CollectionImp and CollectionImp-BuffArr, as private. That works reasonably well for now but I don't like the way it scales. Since libraries load all member vis the package memory footprint will grow as I add different collection implementations (hash table, linked list, etc.) With LV'09 I can designate the Variant Collection class as a friend of my support classes and give all the support class members community scope. I get almost* the same level of protection and instead of loading every collection implementation when LV starts I can dynamically load only the implementation I need at runtime.

*Using friend classes a package user could create new child classes from my support classes. They cannot do that when I wrap my package in a lvlib.

It seems like friend scoping is only present to facilitate lazy coding (purely removing the need to create accessors/mutator for another class' member data!) and, in much of the code I've had to work with, was a backdoor to trouble.

As Paul_at_Lowell alluded, friend scope in LV does not allow direct access to private data. It simply allows you to designate certain methods as 'semi-private' and decide who is allowed to use them. The class designer still has to create accessors to get/set private data.