Coupling and Typedefs in classes

[GregFreeman 16]

I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.

Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.

For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.

I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.

 

[smithd 145]

I've always done a separate 'data' or 'data formats' library. Its generally useful for your situation as well as the lv real-time situation (don't want to load up a bunch of PC-side libs/classes into RT land, but still want type-safe messages). If its all on a single target, I'd probably be lazy and do what I think you said: the target of the message owns the data type. But of course that breaks down if more than one target uses that type.

[Mark Balla 180]

I have decide that if more than one class uses a typedef than is belongs to neither so it goes in a common location.

I do have to find out all the typedefs that are used before copying a class. But prefer it to the coupling of classes that is created when one of them owns the typedef.

Dmitry Sagatelyan's 2018 NIWeek presentation SOLID Actor Programming had an interesting solution to this issue. He creates a application specific translation class. These classes are not intended for reuse and translate outputs from one class to inputs of another. 

[GregFreeman 16]

SmithD's response seems to be the general consensus I think.

Mark, this is a good quote I'm stealing "if more than one class uses a typedef than is belongs to neither "

Interesting about the translation classes. Translating the types was actually something I considered, but then I ruled it out because I thought I'd end up with too many types that were essentially duplicates of each other. I'll take a look at his presentation if I can dig it up.

I started thinking about other languages such as C# and how they would handle this. I realized most methods would return classes or interfaces, not structures. And I started thinking about why that would be decoupled, and it's because the classes being returned are not owned by any other class. So this gave me my answer. Make sure the typedef isn't owned by any other class, and it effectively just becomes a POCO.