Who to own typedefs used by interface methods

[Shiv0921]

Sanity check required.

If I have a typedefd enum going in to an interface method, does the typedef live in the interface class? In the interface library perhaps? Something feels off about the interface owning anything other than methods.  

The inheriting class (class A) uses the typedef, so it could own it, but then if I want Class B to use the interface it would depend on class A. Should the typedef live in a shared space?

[Kyle97330]

Something that might not be obvious about how LabVIEW works is that you can't load just a portion of a LabVIEW class.  if you load one member, you load the whole thing.

As such, my company has started mostly leaving type definitions out of classes at all (Interface or otherwise) unless the type definition needs to use an access scope of some kind (private/protected/community).

Example:

My company has multiple sites, each with its own local test database, so we created an enum in our top-level test data class that was for "site" and was used to determine which database to use.

Later, we discovered that there were other uses for knowing which site software was running on, so we started using that "site" enum in other code, such as our "Access control" library.

We then had an issue where some of the EXEs we were making were getting abnormally large and including a bunch of DLLs that we didn't need.  We found that the access control library was included in the EXE, and since that included a reference to the "Site" enum, it also included the test data class, which included a bunch of DLL references.

Turned out that by including one call to the access control library, it added all VIs in that class to the EXE, which included a few VIs with the site enum in their internals, which then dragged in the whole test data class and all its DLLs.  So we removed the Site enum from the test data class, and suddenly our EXEs were ~3 mb smaller and didn't include a bunch of unneeded DLLs in them any more.

So I would strongly consider not adding them to any class at all.  If you do, just be aware that it could cause unexpected bloat if you put it into any class that has a lot of dependencies in it, so I would then recommend putting it in the place that is least likely to cause dependency chains.

[BertMcMahan]

Kind of depends on how you reference things. If you're directly linking the interface class, then you're pulling it in no matter what. In that case it's fine to include it in the class. If that class is also in a library, then putting it in the library is kinda the same thing. The whole point of the interface class is that it's a lightweight connector that lets you interface with other stuff without pulling in ALL of the other stuff.

If you're dynamically loading from a bunch of stuff at runtime, and don't want to pull in the whole library/class, then you can have yet another "interface" library, but at that point you're saying that your interface itself is too bulky to load... which kinda feels like you're putting too much in the interface class. Having two levels of interfacing seems a little convoluted to me.

I think keeping your eyes on the prize will help clarify things. The goal of an interface is to FULLY contain everything that you need to use to interact with a class, such that you're not interacting with the class directly. If a class owns it, then you have to pull in the interface AND the class itself.

I think for clarity I'd put it in a library alongside the interface class.