I asked this question on SO but someone pointed out that I would be better off h

Question

I asked this question on SO but someone pointed out that I would be better off here. He's most likely right. So here I go!

So I just wanted an opinion. I have 2 different ways to approach the problem. Okay so I have a system that I wanna design toward the future. I have some types of objects wich takes as parameters an object implementing an Interface wich can itself contain another object Implementing another interface and so on.

In this way i have

A(InterfaceB B)->B(InterfaceC C)->C(InterfaceD D) ...
Until i get to a point where the object does not contain another one. Every interfaces implement a common interface. So I have

Parent->InterfaceB   ---   Parent->InterfaceC   ---   Parent->InterfaceD
But InterfaceD does not necessarily implement InterfaceB. Because an interface does not have only one implemention, I have multiple possible trees.

A(InterfaceB B)->B(InterfaceC C)->C(InterfaceD D)->...
and

A(InterfaceB B)->B(InterfaceC Y)->Y(InterfaceZ Z)->...
So my question is this : If i want to manage the possible trees, Am I better off using reflection to generate the possible trees on startup? Or would I be better off to hold the different trees in a xml file that I would parse on startup? I have to keep in mind that those Interface types and their implementations will keep coming on. So every time I add a new type, it has to be managed. I know both solution will work. My question is more like this : What would be the best approach to orient the system toward the future.

To add some context to the situation, here's an example of a case

All those interfaces expose an adaptor. Each adaptor may need another one to do its task. For instance, I have an adaptor wich parse some data. But then this data has to be communicated with a remote target. To do this it can use ethernet, serial port, etc... So I could have a generic parser wich takes a generic communicator. That's one of the different possibilities.

If you need some clarifications dont hesitate!

Explanation / Answer

I've been giving this some thought, and I believe your approach with interfaces is counter-intuitive. If you really need this kind of flexibility, interfaces are the opposite of what you want, because interfaces establish specificity, not generality.

Unless, of course, you have a single interface that looks something like this:

public interface ICommand
{
void Execute(string command);
}
Which is actually what I suggest you do. You can make that string anything you want; no need for any additional interfaces.

If you want to make it a bit more sophisticated, you can pass XML to your command, and deserialize it to an instance of a type. You can even make it polymorphic by adding a parameter that specifies the type you want to deserialize to.

My point is that trying to specify your command interface using Interfaces is de-generalizing, which is the opposite of what you want.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.