El patrón en sí realmente no prescribe cómo manejar esto.
Mi propia preferencia es un centro de mensaje/evento donde los presentadores pueden registrar interés en ciertos eventos. Evita árboles de dependencia complejos y mantiene a los presentadores a prueba.
Por ejemplo:
class PresenterA
{
void HandleProductSelectionChanged(int productId)
{
EventHub.Publish(EventType.ProductChanged, productId);
}
}
class PresenterB
{
void PresenterB
{
EventHub.Register(EventType.ProductChanged, HandleProductChanged);
}
public void HandleProductChanged(object state)
{
var productId = (int)state;
var productDetails = LoadProductDetails(productId);
view.DisplayProductDetails(productDetails);
}
}
EventHub mantendría una lista de suscriptores para invocar para cada tipo de evento.
Mantiene su capacidad de prueba: simplemente llame al HandleProductChanged
para ver cómo respondería el presentador a una nueva selección de productos.
La única desventaja (como con cualquier patrón) es que introduce un nivel de indirección. Si PresenterA invocó directamente PresenterB, o PresenterB escuchó un evento en PresenterA, es obvio lo que va a suceder inmediatamente.
En este enfoque, tendría el paso adicional de ver EventType.ProductChanged, y luego encontrar qué presentadores mostraron interés en ese evento.
Según mi propia experiencia, ese único nivel de indirección vale la pena modularidad.
Esto es exactamente lo que estaba buscando, se ve mucho mejor que pasar las referencias del presentador. Voy a echar un vistazo a esto mañana cuando no estoy tan cansado. Gracias. – user1277327