Interface implementation between two projects

Question

from searching a solution to my circular reference problem between two projects, I came across this:

You can have A depend on B. For simplicity lets say A.EXE depends on B.DLL. Then when A initially calls B, it can give it an object of some type or interface that is defined in B and then B can turn around and call back into A at some later point.

In other words, B defines a base class or interface like "I want something that only A can do" but don't implement it. Then let A implements it, passes it to you, and calls it. This gets around the circular dependency without a third project. This applies to any pair of managed projects.

I tried implementing what was said, but I don't seem to get it right. So my question is, could someone provide me a code example on how to achieve this (VB.Net preferably, C# will do) ?

For reference the original question is here: Solving circular project dependency between C# and C++/CLI projects?

It's hard to understand what you're trying to do without a more concrete example. But it sounds like your problem might be solved or at least helped by a class library that multiple projects can reference. That way they're both working with the data in similar ways. — mason, Jan 17 '14 at 19:11
For the downvoters, there you go, Adam Robinson actually helped me a lot with his answer. Jeezes .. I didn't provide code because I thought the quoted text was clear enough. (obviously I wasn't that wrong with that thought since there's a really good answer already). — Frank, Jan 17 '14 at 19:34
@Frank: The thing you need to realize is that we here at SO exist to help you fix your code, not explain design patterns from scratch. There are better resources for such things. We understand that you just want an answer to something you don't understand. We've all been there. Just remember that the StackExchange contains many sections, and they're rather focused. This one exists for issues in code. — Magus, Jan 20 '14 at 15:34
@Magus: I see, thank you for taking time to explain this. I've got to say I prefer answers (and questions) that provide code, easier and faster to determine if your problem is related. Thing is, I spend a LOT of time here, searching for the most part, and I often see questions about such design patterns, or just a quick helper to grasp a concept. I'm sorry if the questions helps no one else, but truly, 2 minutes after Adam's answer I was on my way... and I had spent most of my day on this. Anyhow, I'll try to be clearer in the future. Cheers. — Frank, Jan 20 '14 at 17:02

score 3 · Accepted Answer · answered Jan 17 '14 at 19:12

Just a minor nitpick. This isn't a real circular dependency, as the idea that "this is something only A could do" is faulty. All B really knows is that "this is something that only someone else can do". It may be true that only A can do it, but that isn't known to B.

Anyhow, a simple example would be this:

In assembly B:

public interface ISomething
{
    void PerformAction();
}

public class ActionManager
{
    public void DoSomething(ISomething something)
    {
        something.PerformAction();
    }
}

In assembly A (which references B):

public class ActionPerformer : ISomething
{
    public void PerformAction()
    {
        ...
    }
}

public class Program
{
    public static void Main()
    {
        ActionManager manager = new ActionManager();
        ActionPerformer performer = new ActionPerformer();

        manager.DoSomething(performer);
    }
}

In short, this example demonstrates code that (after full polymorphic resolution) has A call into B, then B calling back into A.

Interface implementation between two projects

1 Answers1