Is two way 1-n relationship between classes acceptable?

Question

I met a problem like this.

class A have a list of class B. A have choose one of B, and call its method. So A depends on B.

But when a timer ( not a real timer, just a mimic clock ) fires, B have to tell A that "I am done", so A can choose another B to work, which means B has to know A also.

This is a "two way 1-n relationship" and I think A and B are not well seperated.

Of course I can use Observer Pattern and make A an observer and B a subject, but this is not a typical case where observer pattern make sense because there is only one observer.

What do u think about it?

Answer 1

There is only one observer NOW, but who knows in the future?

A gets a B. B exposes an event that A (or anyone else for that matter) subscribes to. B fires the event, A gets the message.

B does not know about A it only knows about its own event.

Answer 2

I agree with n8wrl that an event is probably a cleaner solution.

Original answer:

Does B need to know about all possible A's or just the one that called it (the one it tells "I am Done")? If so, then A can have the list of All B's, and B can have a reference to only the one A that matters.

Here's how I'd do it. Yes there's a cyclic association, but there's some control in how it's used. And this can eventually be refactored to a purer observer pattern if required.

class A
{
  List<B> bObj = new List<B>();

  public void callB(/*Params*/)
  {
    B bThatMatters = //Find Appropriate B ...
    bThatMatters.DoStuff(this);
  }

  public void isDone()
  {
     //Handle being done with the last B
  }
}

class B
{
   A _callerA;

   public void DoStuff(A callerA)
   {
      _callerA = callerA;

     //... DO STUFF
   }

 public void WhenDone()
 {
    _callerA.isDone()
 }
}

Answer 3

A knows about the available Bs. B only knows about the A currently using him. I don't think that's 1-n is it?

But B doesn't depend upon A as such, he does not care it's an A. He just needs to use the "finished()" method of his temprary associate. There's no real dependency there.

Class A implements ClientOfB {
       Collection<B> myBees;

       public beNottified() { ...}

       public employeeBee () {
             myBees.getRandomBee().buzz(this);
       }

}

Class B {
    public void buzz(ClientOfB client) {
          client.beNotified();
    }
}

I don't see unreasonable dependencies. A needs to know about buzz and to expose an interface. B only knows about the interface.