Question

in my application I’ve got three interfaces ICapture<T>, IDecoder<T, K>, and IBroadcaster<K>.

Now I implement for example a VideoCapture class inheriting from Capture<IntPtr> (IntPtr is the raw data produced by the class). When data is generated by an object of VideoCapture, I firstly want to decode it from T to K, and then broadcast it.

What I want to know is: how would you chain this ? Simply by writing a method like

var data = videoCapture.GetData();
var decoded = decoder.Decode(data);
broadcaster.Broadcast(decoded);

Or are there any design patterns, that I could use? I know of the chain of responsibility pattern. I could imagine writing classes like CaptureHandler, DecoderHandler, and BroadcastHandler inheriting from HandlerBase. HandlerBase would provide mechanisms to hand over objects to the next handler.

var handler1 = new CaptureHandler();
var handler2 = new DecodeHandler();
handler1.SetNext(handler2);
handler1.Handle(object);

But I dunno if this is the best approach for my situation.

Answer 1

You could an instance of each object into the constructor of the next. If for example, every decoder instance needs a video capture instance to work, then you can have a constructor as follows …

Decoder(VideoCapture<T> captureDevice)
{
}

And do the same thing for the Broadcaster, i.e have a constructor that will take in a decoder instance as a parameter.

In fact, I am not even sure you would need generics. You might do, depending on your application. We can only see a small part in this question after all. Not sure what Types you will be passing into each of these classes either and how the Type parameter will be used inside them.

But if I was to hazard a guess, I think just normal OO hierarchy would be the best, simplest way to go.

So, have a Capture base class, which has the virtual method GetData(). You will then create sub classes for different kinds of Capturing you do. “CapturePal”, “CaptureSecam”, “CaptureMeSecam” etc. Again, I am guess that sub classing would be enough for you rather than a generic Type parameter (would Capture<float>() as well as Capture<StringBuilder>() be meaningful in your application?)

So once you have a base class and subclasses for your capture functionality, do the same for your Decoder and Broadcaster classes. Base class Decoder, sub class “DivxDecoder”, “MpegDecoder”. Base class Broadcaster with subclass “TVBroadcaster”, “IPBroadcaster”, “TCPBroadcaster” etc.

Now, the constructors for each of the base classes will take the other base class as a parameter and call the appropriate methods.

This will allow you to chain them as follows

var myProcessingChain = new TVBroadcaster(new DivxDecoder (new CaptureSecam(inputData))));

assuming that all the capture classes take the same input type.

The other option is to use Interfaces. If your application has some classes that can act as both a capturer and a decoder for example.

Think a bit more about whether you really need Generics. Generics are helpful when you want to reuse algorithms and want to be agnostic to the Type, while enforcing Type safety. Being agnostic to Type is different from being able to accept a set of Types that share a commonality. In this case you can get the commonality among the Types by using inheritance.