Allow me to abstract the problem I quite often face with actors, and what the common design pattern to solve it. Suppose I have the following actor hierarchy:
── user
└── ServiceActor
├── TicketManager
│ ├── WorkerA
│ ├── WorkerB
│ └── WorkerC
└── UserManager
├── WorkerA
├── WorkerB
└── WorkerC
The hierarchy beyond the first level, i.e Ticket and User Managers are unimportant. I have a requirement that TicketManager fires messages to UserManager and vice versa. (Note that these are just example names I've used and is not representative of any real problem)
Which of the following is the most appropriate?
Option 1:
TicketManager constructor takes UserManager as a constructor argument. UserManager constructor takes TicketManager as a constructor argument. However, both can't have recursive calls to each other, so this is probably not possible anyway.
Option 2:
UserManager makes a reference to TicketManager via an actorSelection as actorSelection("../TicketManager") and so on on requirement, or only once on startup and keeps it.
Option 3:
At any given point of time, UserManager/TicketManager asks their parent (ServiceActor) for a reference to their other sibling and is appropriately replied back with an actorRef as the parent holds that reference.
Option 4:
Should this never be a situation? Should I not think of siblings talking to each other as it "complicates" design in some way? Should there be a more tree-like hierarchy? What is a common design pattern that may help avoid it if that's the case?
I hope I've made the requirement clear, please allow me to clarify further if needed?
Aucun commentaire:
Enregistrer un commentaire