views:

143

answers:

2

I have written a small GUI based vb.net program that speaks to embedded devices via the com port. The GUI code contains a class which all communication to the embedded device is handled through (com port device, communication protocol, parsing info, holding device related info after each read).That class is called EDComms.

I wanted to add a thread so that the EDComms object could run in the background and report back as it downloads logs files and such (It can take a while to get log files from the device sometimes).

So. Should I have EDComms inherit from backgroundworker thread? Or should I have a background worker thread as a member of EDComms?

Right now I am going with the second choice. The only thing I have to do now is write a func for registering two delegates from the GUI for notifying task progress, and notifying task complete.

Of these two choice, have I picked the better? Or is there a better choice than these two I have presented Perhaps have the thread as a member of the GUI?

Thanks.

+1  A: 

When you inherit from a class, you are implying an IS A relationship. EDComms is not a thread. Having it manage the thread is one approach, or you might have a background worker external to the class all together. But I would say the only option that shouldn't be an option, is the inheritence option.

Based on what I know about your application, you have selected the best option.

NerdFury
+1  A: 

Really, either is OK. It's more a matter of what you want the thread to mean from a design standpoint. Is the EDComms object going to be doing the work itself or would you rather have the EDComms object simply wrap the worker and provide an interface to communicate with it. Personally, I like your choice better, I think it makes logical sense, but that's just my opinion.

Chris Thompson