¿Patrón de diseño apropiado para un analizador de registro de eventos?

Question

Trabajando en un proyecto que analiza un registro de eventos y luego actualiza un modelo basado en las propiedades de esos eventos. He sido muy perezosa sobre "hacer las cosas" y más preocupado por la optimización inicial, el código delicado y los patrones de diseño adecuados. Sobre todo, un experimento autodidacta. Me interesan los patrones que los diseñadores más experimentados consideran relevantes, o qué tipo de arquitectura de objetos pseudocodificados sería la mejor, la más fácil de mantener, etc.

Puede haber 500,000 eventos en un solo registro, y hay alrededor de 60 tipos de eventos, todos los cuales comparten aproximadamente 7 propiedades base y luego tienen de 0 a 15 propiedades adicionales según el tipo de evento. El tipo de evento es la segunda propiedad en el archivo de registro en cada línea.

Así que he intentado con un analizador sintáctico realmente feo que recorre el registro línea por línea y luego procesa los eventos línea por línea. Luego probé una especificación léxica que usa un patrón "nextEvent", que se llama en un ciclo y se procesa. Luego probé un método simple y antiguo de "análisis sintáctico" que nunca regresa y simplemente activa eventos para llamadas de escucha registradas. Intenté una devolución de llamada única independientemente del tipo de evento y un método de devolución de llamada específico para cada tipo de evento.

He intentado una clase base de "eventos" con una unión de todas las propiedades posibles. Intenté evitar la llamada al "nuevo evento" (ya que puede haber una gran cantidad de eventos y los objetos del evento generalmente son de corta duración) y tener los métodos de devolución de llamada por tipo con argumentos de propiedad primitivos. Intenté tener una subclase para cada uno de los 60 tipos de eventos con un elemento primario de evento abstracto con las 7 propiedades básicas comunes.

Recientemente traté de llevar eso más allá y usando un patrón de comando para poner el código de manejo de eventos por tipo de evento. No estoy seguro de que me guste esto y es realmente similar a las devoluciones de llamada por enfoque de tipo, solo el código está dentro de una función de ejecución en las subclases de tipo frente a los métodos de devolución de llamada por tipo.

El problema es que una gran parte de la lógica de actualización del modelo es compartida, y muchas de ellas son específicas de la subclase, y estoy empezando a confundirme sobre el asunto. ¡Espero que alguien pueda al menos señalarme en una dirección para considerar!

Answer 1

Bueno ... para una cosa en lugar de una única clase de evento con una unión de todas las propiedades, o 61 clases de eventos (1 base, 60 subs), en un escenario con tanta variación, me sentiría tentado tener una única clase de evento que utiliza una bolsa de propiedades (diccionario, hashtable, w/e flota su bote) para almacenar información del evento. El tipo de evento es solo un valor de propiedad más que se pone en la bolsa. La razón principal por la que me inclinaría de esa manera es solo porque detestaría mantener 60 clases derivadas de cualquier cosa.

La gran pregunta es ... ¿qué tiene que hacer hacer con los eventos a medida que los procesa. ¿Los formatea en un informe, los organiza en una tabla de base de datos, despierta a la gente si ocurren ciertos eventos ... qué?

¿Está destinado a ser un analizador posterior al hecho o un controlador de eventos en tiempo real?Quiero decir, ¿está monitoreando el registro a medida que entran los eventos, o simplemente analizando los archivos de registro al día siguiente?

Answer 2

Posiblemente Hashed Adapter Objects (si se puede encontrar una buena explicación de la misma en la web - que parece que falte.)

Answer 3

Considérese una fábrica de peso mosca de los objetos de estrategia, uno por cada 'clase' del evento.

Para cada línea de datos de eventos, busque la estrategia de análisis apropiada de la fábrica flyweight, y luego pase los datos del evento a la estrategia para el análisis. Cada uno de los 60 objetos de estrategia podría ser de la misma clase, pero configurados con una combinación diferente de objetos de análisis de campo. Es un poco difícil ser más específico sin más detalles.

Answer 4

No estoy seguro de entender el problema correctamente. Supongo que hay una 'lógica de actualización modelo' compleja. No distribuyas esto a través de 60 clases, mantenlo en un solo lugar, aléjalo de las clases de eventos (patrón Mediator, más o menos).

Su Mediador funcionará con clases de eventos (no veo cómo podría usar el Flyweight aquí), los eventos pueden analizarse por sí mismos.

Si las reglas de actualización son muy complicadas, no se puede abordar el problema con un lenguaje de programación de propósito general. Considere usar un motor basado en reglas o algo por el estilo.

Answer 5

Justo al lado de la parte superior:

me gusta la sugerencia en la respuesta aceptada por tener sólo una clase con un mapa de propiedades. También creo que el behvavior se puede montar de esta manera también:

class Event 
{ 
    // maps property name to property value 
    private Map<String, String> properties; 

    // maps property name to model updater 
    private Map<String, ModelUpdater> updaters; 

    public void update(Model modelToUpdate) 
    { 
     foreach(String key in this.properties.keys) 
     { 
      ModelUpdater updater = this.updaters[key]; 
      String propertyValue = this.properties[key]; 

      updaters.updateModelUsingValue(model, propertyValue); 
     } 
    } 

} 

La clase ModelUpdater no se representa. Actualiza su modelo basado en una propiedad. Me inventé el bucle; esto puede ser o no el algoritmo en realidad. Probablemente haga de ModelUpdater una interfaz más. Cada implementador sería por propiedad y actualizaría el modelo.

Entonces mi "bucle principal" sería:

Model someModel; 

foreach(line in logFile) 
{ 
    Event e = EventFactory.createFrom(line); 
    e.update(someModel); 
} 

EventFactory construye los eventos del archivo. Rellena los dos mapas en función de las propiedades del evento. Esto implica que hay algún tipo de forma de hacer coincidir una propiedad con su actualizador de modelo asociado.

No tengo ningún nombre de patrón de lujo para usted. Si tiene algunas reglas complejas, como si un Evento tiene las propiedades A, B y C, entonces ignore el actualizador del modelo para B, entonces este enfoque tiene que extenderse de alguna manera. Lo más probable es que necesite inyectar algunas reglas en EventFactory de alguna manera utilizando el patrón de objeto de regla. ¡Aquí tienes, hay un nombre de patrón para ti!