Question

I’m looking to do both synchronous communication (over serial) using .NET’s SerialPort and also have asynchronous communication (over Ethernet) using .NET’s Socket.

The current implementation has a Connection class that declares both a SerialPort and Socket, and depending on what the user has defined the device’s connection type in the GUI–either COM or Ethernet–the Connection class will initialize the appropriate serial or socket port.

I have a ConnectionManager that holds all the Connections. So if the user creates a device using the same connection info, it doesn’t create a new Connection; instead, it is just assigned the Connection that is found in ConnectionManager.

This is a problem, because I need to do synchronous communications as well as asynchronous. What happens is there is a loop that creates Tasks while I’m connected to a device and each Task is trying to do a Send and Receive, and since it takes longer for the device to complete a task, than it takes the software to create tasks, there is a lot concurrency problems (blocked threads). Since I need to do synchronous communication, I lock a Mutex before my send Send and release the mutex after my Receive–to assure for every Send I get a Receive. This is not good because then when I would try to do Async communications it will be throttled due to the mutex.

So my question is what is the best design to follow when trying to handle asynchronous and synchronous communications at the same time? Should there be two different connection classes (AConnection, BConnection) that inherit a Connection interface with Send, Receive, Open, Close methods?

Any help is appreciated.

Answer 1

In general, you should alway prefer object composition over class inheritance. What that means is, instead of creating a super-class (say WorkClass) with most of the functionality that you need and then two concrete sub-classes that inherit from it (say AWorkClass : WorkClass and BWorkClass : WorkClass) and use/override those functions, you should crease two concrese classes with no inheritance (AClass and BClass) which “have a” WorkClass as a member variable.

Taking this a bit further, and ultimatley trying to answer your question, it sounds like you want to implement the Strategy Pattern which will allow you to switch “strategies” (like between sync and async communication) very easily and allows you to add new “strategies” down the line without much effort (or make modifications to existing ones without having to worry about ripple-effects as much).

Here is a sample Strategy implemented in C#:

namespace Your.App
{
//correct implementation of the Strategy Pattern
    interface ICommunication
    {
        void Send();
    }
    class SyncCommunication : ICommunication
    {
        public void Send() { /*your sync code*/ }
    }
    class AsyncCommunication : ICommunication
    {
        public void Send() { /*your async code*/ }
    }
    public class WorkClass
    {
        ICommunication Strategy { get; set; }
        public WorkClass()
        {
            UseAsync = false;
        }
        bool _useAsync;
        public bool UseAsync 
        {
            get { return _useAsync; }
            set
            {
                _useAsync = value;
                if(_useAsync)
                    Strategy = new AsyncCommunication();
                else
                    Strategy = new SyncCommunication ();
            }
        }
        public void Send()
        {
            Strategy.Send();
        }
    }
}

To tie this in with the first paragraph, then use WorkClass like this:

namespace Your.App
{
//correct implementation of the Strategy Pattern
    public class MyWorkContext
    {
        WorkClass Worker {get; set;}
        public MyWorkContext()
        {
            Worker = new WorkClass();
        }

        public void SendMyData()
        {
            if(someConditionIsMet)
                Worker.UseAsync = true;
            else
                Worker.UseAsync = false;
            Worker.Send();
        }
    }
}

You can see that the user of your WorkClass (which is MyWorkContext in this case) doesn’t know anything about your strategies, nor should it. It just tells the worker enough for it to know what to do, and then the worker knows which strategy it needs to use to do it. The strategies themselves are the only ones that know how the work is actually done, which is really nice for testing and maintenance.