Un proveedor es en realidad otro nombre para el Strategy Pattern
Normalmente, cuando alguien menciona el uso de un proveedor que están hablando de algunos contratos abstracta a la que podrían existir muchas implementaciones.
//As an abstract base class
public void SetupRoles(RoleProvider provider){}
//As an interface
public void SetupRoles(IRoleProvider provider){}
//As a delegate
public void SetupRoles(Action<String> addRole){}
Un servicio suele indicar un objeto sin estado que solo tiene métodos. Un servicio podría ser utilizado como una Estrategia, pero no necesariamente tiene que serlo.
//Plain old service... doesn't even need the web
// CRAZY TALK MAN!!!
public static class RoleService
{
public static void SetupRoles(){};
public static String[] GetRoles(){};
}
Un Broker es realmente responsable de la intermediación así .... Está diseñado para mover mensajes entre servicios y objetos, orquestando las interacciones entre servicios para mantenerlos aislados.
public class Broker
{
public void SendImportantMessage(Message msg)
{
//Do some important processing here
// Maybe some validation
NotifySomeOtherServiceOrClassOrMaybeBobFromAccounting(msg);
}
}
una pregunta interesante, pero (Proveedor de Servicio, Broker) se refiere a las reglas de denominación. ¡No es un patrón de diseño (como admites en tu título)! ¿Estas de acuerdo conmigo? –
Tengo entendido que existen patrones de diseño de Proveedor y Corredor, pero podría estar equivocado. Sin embargo, sí, tiene razón, mi pregunta específica es sobre la convención de nomenclatura del comportamiento que estoy presentando. Cómo nombrar la (s) clase (es) a la que estoy descargando la responsabilidad. – Shawn
Un intermediario transfiere datos o eventos entre otros objetos. Toma un rol más activo que (por ejemplo) un proveedor, pero tiende a ser solo para la transferencia. Un poco como un corredor de la vida real, en realidad no proporciona servicios en sí mismo. –