In terms of inheritance, you could do that by deriving the class describing. Now of course, there are some problems when all them interface implement a function with the same signature, say void Update(): which Update() should be called in your case? The one from A? Or B? Or C? I personally don't like C, as a vitamin at least it is sour.

This is where COM ... comes in place. In COM, if you want to implement an interface on an object, you'll get a new instance of a class. That means that somehow, in your objects, you'll have at least three class instances, one that implements the functionality of A, one for B, well, you get the point.

Why the frowned face? Oh, stupid me, I forgot something: from now on, your object is no longer an instance of one class. No. That's gone. Think of it as a collection of classes, each working together to provide functionality for one object.

Now I can hear you saying: "But what if I need to use functionality from Interface A in the implementation of Interface B? How can I reach one functionality from the other?"

In all technologies that implement an object modeling mechanism (yep, that's the OM from COM), there will always be a mechanism to go from one interface to the other. In COM, it is called "QueryInterface". In Unity, you GetComponent.

Now it makes sense. This is why the First Person Controller prefab in Unity looks like this:

You'll see that I underlined two components (get used to the term if you plan to use Unity). If you double click them, you'll end up looking at some C# code. Each of the scripts describe a class, each having a Start() and Update() function. Several components, working to define one object.And here's another thing about COM: you can re-use components:

The Mouse Look script is the shared component here.

That's it. Don't say I didn't warn you, if you know COM this was not a surprise.