Подходящий шаблон проектирования для парсера журнала событий?

Question

Работа над проектом, который анализирует журнал событий, а затем обновляет модель на основе свойств этих событий. Я был довольно ленив в том, чтобы "сделать это", и больше беспокоился об оптимизации, бережливом коде и правильных шаблонах проектирования. В основном эксперимент с самообучением. Меня интересует, какие шаблоны, по мнению более опытных дизайнеров, актуальны или какой тип архитектуры объектов с псевдокодированием будет лучшим, простым в обслуживании и т. Д.

В одном журнале может быть 500 000 событий, и существует около 60 типов событий, каждый из которых имеет около 7 базовых свойств, а затем имеет от 0 до 15 дополнительных свойств в зависимости от типа события. Тип события - это второе свойство в файле журнала в каждой строке.

Итак, я попробовал действительно ужасный императивный парсер, который построчно просматривает журнал, а затем построчно обрабатывает события. Затем я попробовал лексическую спецификацию, которая использует шаблон «nextEvent», который вызывается в цикле и обрабатывается. Затем я попробовал простой старый метод "parse", который никогда не возвращается и просто запускает события для зарегистрированных обратных вызовов слушателя. Я пробовал как один обратный вызов независимо от типа события, так и метод обратного вызова, специфичный для каждого типа события.

Я пробовал базовый класс "событие" с объединением всех возможных свойств. Я попытался избежать вызова «нового события» (поскольку может быть огромное количество событий, а объекты событий, как правило, недолговечны) и наличия методов обратного вызова для каждого типа с аргументами примитивного свойства. Я попытался создать подкласс для каждого из 60 типов событий с абстрактным родителем события с 7 общими базовыми свойствами.

Недавно я попытался пойти дальше и использовать шаблон Command для добавления кода обработки событий для каждого типа события. Я не уверен, что мне это нравится, и оно действительно похоже на методы обратного вызова для каждого типа, просто код находится внутри функции execute в подклассах типов по сравнению с методами обратного вызова для каждого типа

Проблема состоит в том, что большая часть логики обновления модели является общей, и большая ее часть относится к подклассу, и я только начинаю путаться во всем этом. Я надеюсь, что кто-то может, по крайней мере, указать мне направление, чтобы рассмотреть!

Answer 1

Ну ... во-первых, вместо одного класса событий с объединением всех свойств или 61 класса событий (1 базовая, 60 подпрограмм), в сценарии с таким большим количеством вариаций я бы соблазнился иметь один класс событий, который использует пакет свойств (словарь, хеш-таблица, с плавающей запятой) для хранения информации о событии. Тип события - это просто еще одно значение свойства, которое помещается в сумку. Основная причина, по которой я склоняюсь к этому, заключается в том, что мне не хотелось бы поддерживать 60 производных классов чего-либо.

Большой вопрос ... что вам нужно делать с событиями, когда вы их обрабатываете. Вы форматируете их в отчет, организуете их в таблицу базы данных, будите людей, если происходят определенные события ... что?

Должен ли это быть анализатор после факта или обработчик событий в реальном времени? Я имею в виду, вы отслеживаете журнал по мере поступления событий или просто анализируете файлы журнала на следующий день?

Answer 2

Рассмотрим фабрику Flyweight объектов Стратегии, по одному на «класс» события.

Для каждой строки данных о событиях найдите подходящую стратегию синтаксического анализа на фабрике с навесным весом, а затем передайте данные о событиях в стратегию для анализа. Каждый из 60 объектов стратегии может относиться к одному и тому же классу, но может иметь различную комбинацию объектов разбора полей. Немного сложно быть более конкретным без подробностей.

Answer 3

Сверху:

Мне нравится предложение в принятом ответе о наличии только одного класса с картой свойств. Я также думаю, что bevavior также может быть собран таким образом:

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);
        }
    }

}

Класс ModelUpdater не показан. Он обновляет вашу модель на основе свойства. Я составил петлю; это может или не может быть тем, чем на самом деле является ваш алгоритм. Я бы, вероятно, сделал ModelUpdater более интерфейсным. Каждый реализатор будет для каждого свойства и будет обновлять модель.

Тогда мой "основной цикл" будет:

Model someModel;

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

EventFactory создает события из файла. Он заполняет две карты в зависимости от свойств события. Это подразумевает, что существует какой-то способ сопоставления свойства с соответствующим модулем обновления модели.

У меня нет причудливых названий шаблонов для вас. Если у вас есть несколько сложных правил, например, если событие имеет свойства A, B и C, а затем игнорируйте средство обновления модели для B, то этот подход необходимо как-то расширить. Скорее всего, вам может понадобиться внедрить некоторые правила в EventFactory, используя шаблон объекта правил. Вот, пожалуйста, название шаблона для вас!

Answer 4

Возможно Хэшированные объекты-адаптеры (если вы можете найти хорошее объяснение этого в Интернете - их, похоже, не хватает).

Answer 5

Я не уверен, что правильно понял проблему. Я предполагаю, что есть сложная «логика обновления модели». Не распространяйте это по 60 классам, держите его в одном месте, уберите его из классов событий (шаблон Mediator, вроде).

Ваш Посредник будет работать с классами событий (я не понимаю, как вы можете использовать Flyweight здесь), события могут анализироваться сами.

Если правила обновления очень сложны, вы не сможете решить проблему с помощью языка программирования общего назначения. Подумайте об использовании движка на основе правил или чего-то в этом роде.