actionscript-3 - last - rabbitmq net

Simplicidad de protocolo versus "propiedad"

Question

Tengo otra discusión con un amigo mío.

Considere la necesidad de diseñar un protocolo simplista basado en JSON, que básicamente se utiliza para enviar tipos de eventos (mensajes) entre las partes.

Diga algo como

 { event_id: 1, chat_message: "Hello" }
 { event_id: 2, group_id: 3, presence: "online" }
 ...

Propongo mantener este protocolo justo como arriba, mientras mi amigo propone hacer algo como:

 { event_id: 1, details: { chat_message: "Hello" } }
 { event_id: 2, group_id: 3, details: {  presence: "online" } }
 ...

Su argumento es que, al igual que TCP y, por ejemplo, HTTP están en diferentes niveles de "responsabilidad", este protocolo debe usar el subobjeto "detalles" para mantener separados los datos.

Otro argumento que tiene es que los manejadores que manejan eventos coincidentes, no deberían saber nada acerca de la información de "enrutamiento" (cosas como event_id).

Mis argumentos son:

1. Estamos aumentando la duración de cada mensaje (y el tráfico de la red, esto puede ser importante para un sistema que intercambia con muchos mensajes) por el bien de ocultar esta información de los controladores

2. Los manejadores realmente necesitan saber la información de "enrutamiento", por ejemplo, para responderlos correctamente:

   this.replyTo(event[''event_id''], reply); // or...
   this.replyTo(event, reply); 

3. Incluso si necesitaremos ocultar event_id y cosas así de los manejadores, podemos quitarlos antes de pasarlos a los manejadores y así ahorrar aún en tráfico

Este protocolo es bastante simple y no debe ser utilizado por nadie más.

Que piensas?

Answer 1

Favorecer la simplicidad ...

Se requerirá la corrección cuando escriba una especificación, un sistema distribuido y uno que se utilizará en muchas circunstancias diferentes fuera de su control.

Siendo pragmático , a menudo es mejor usar el "poder del lenguaje" y simplemente escribir código para manejar cada caso. No abstraiga a menos que lo necesite .

Mantenlo simple. Mantenlo rápido. Mantenlo limpio.

No sabe en qué puede evolucionar (características o rendimiento), y cuanto más abstracción tenga, más difícil será volver a factorizar.

Answer 2

Hubo un tiempo en que ARPAnet todavía era nuevo y la IP todavía era una fuente de una idea, alguien dijo "Oh, caramba, una dirección IP de 32 bits es suficiente, ¿cuatro mil millones de direcciones? Nadie nunca necesitará eso. Diablos, nosotros puede dividirlos en diferentes tipos de direcciones, hay mucho espacio ".

Poco sabíamos, 25 años después, que sería un problema.

Y ni siquiera me hables sobre el nombre de dominio.

El punto es este: debes pensar en lo que puede cambiar. Hacer esto en una jerarquía de espacios de nombres solo por elegancia es innecesario y derrochador, y cuando su capa adicional no proporciona más contenido de información, entonces ¿para qué molestarse?

Por otro lado, si lo hace para que su código sea menos sensible a los cambios en el problema, o para que la implementación sea notablemente más fácil o menos propensa a errores, entonces bien podría valer la pena.

Entonces, está su respuesta: ¿es solo para ser más elegante o tiene otras ventajas?

Answer 3

Estas son dos soluciones correctas . Si realmente tiene que preocuparse por el tráfico de red, su solución es aceptable. Pero también debe recordar que el mantenimiento del código ocupa la mayor parte de la vida útil del código, por lo que al hacer el código más limpio hoy probablemente ahorrará tiempo en el futuro (mantenimiento mencionado anteriormente).

En mi opinión, debería tener buenos argumentos basados ​​en hechos importantes para pensar en ese tipo de optimizaciones.

Answer 4

Después de una larga experiencia en un gran proyecto, debo estar totalmente en desacuerdo con las sugerencias de Gahooa y Charlie Martin . Hay una gran tensión entre el enfoque ágil y clásico. Sus sugerencias pueden parecer ágiles, pero no puedo estar de acuerdo. Si diseña algo, nunca lo diseñe de manera que sepa que está mal incluso ahora. No es ágil, es tonto. No puedo creer que piense que sus requisitos no cambiarán en el futuro, así que mantenga las puertas abiertas y el impacto de la refactorización mínimo. Cuando en su evento de diseño actual es manejado por diferentes subsistemas como dispatcher de tipo de evento -> router to group -> controlador de evento final / storage o lo que sea, mantenga el cambio en cada subsistema con un impacto mínimo entre sí. El mejor costo para mí es el protocolo de diseño, como la yema de cáscaras de cebolla, no lo diseñe para cada detalle sutil fuera de sus requisitos actuales . Es ágil.

Usted argumentos:

anuncio 1. Es una optimización prematura. Si realmente necesita minimizar el tráfico, use un protocolo binario ;-) Otra forma costo / beneficio de ti es incorrecto.

anuncio 2. Es el trabajo para la instrumentación del programa interno, no para el protocolo en sí. Es un diseño incorrecto especialmente en Erlang. Su manejador no debe regresar directamente al destino sino a algún enrutador (generalmente de regreso al despachador) que mantiene la propiedad del socket y similar. ¡Parece una optimización prematura de nuevo!

anuncio 3. Prefiero el enfoque opuesto. Proporcione un conjunto de datos mínimo a los subsistemas para minimizar los efectos secundarios, simplifique las pruebas (de la unidad) y evite la seducción para usar el enfoque desde 2. punto. Extender si es necesario. No lo hagas de manera opuesta.

PD: ¿Por qué no nombras tu evento pero usas identificadores? Optimización prematura de nuevo?

Editar: Los ID se aclaran, son números de evento pero no clases de evento. Debería haber otra clave de clase.