Question

处理解析事件日志的项目，然后根据这些事件的属性更新模型。我一直懒得“完成它”，更关注前期优化，精益代码和适当的设计模式。主要是自学实验。我感兴趣的是更有经验的设计师认为相关的模式，或者哪种类型的伪编码对象架构是最好的，最容易维护的等等。

单个日志中可以有500,000个事件，并且大约有60种类型的事件，所有这些事件共享大约7个基本属性，然后根据事件类型具有0到15个其他属性。事件类型是每行日志文件中的第二个属性。

因为我尝试了一个非常丑陋的命令式解析器，它逐行遍历日志，然后逐行处理事件。然后我尝试了一个使用“nextEvent”模式的词法规范，该模式在循环中被调用并被处理。然后我尝试了一个简单的旧“解析”方法，该方法永远不会返回，只是将事件触发到已注册的侦听器回调。无论事件类型如何，我都尝试过一次回调，以及特定于每种事件类型的回调方法。

我尝试过一个带有所有可能属性的联合的基础“事件”类。我试图避免“新事件”调用（因为可能存在大量事件并且事件对象通常是短暂的）并且每种类型的回调方法都具有原始属性参数。我已经尝试为60个事件类型中的每一个设置子类，并使用具有7个公共基本属性的抽象事件父类。

我最近尝试进一步使用Command模式为每个事件类型放置事件处理代码。我不确定我是否喜欢这个并且它与每种类型的回调方法非常相似，只是代码在类型子类中的执行函数内，而不是每种类型的回调方法。

问题在于很多模型更新逻辑是共享的，而且很多都是特定于子类的，我只是开始对整个事情感到困惑。我希望有人能够至少指出我的方向来考虑！

Answer 1

嗯...对于一件事，而不是一个具有所有属性的联合的事件类，或者61个事件类（1个基数，60个子），在具有这么多变化的场景中，我很想尝试有一个事件类，它使用一个属性包（字典，哈希表，w / e漂浮你的船）来存储事件信息。事件的类型只是一个属性值，可以放入包中。我倾向于这种方式的主要原因仅仅是因为我不愿意维护60个派生类。

最大的问题是......当你处理事件时，你有什么做事件。您是否将它们格式化为报告，将它们组织到数据库表中，如果发生某些事件则唤醒人们......什么？

这是一个事后解析器，还是一个实时事件处理程序？我的意思是，您是在事件进入时监控日志，还是仅在第二天解析日志文件？

Answer 2

考虑一个策略对象的Flyweight工厂，每个“一类”事件。

对于每一行事件数据，从flyweight工厂查找适当的解析策略，然后将事件数据传递给策略进行解析。 60个策略对象中的每一个都可以是同一个类，但配置了不同的字段解析对象组合。如果没有更多细节，那就更难具体了。

Answer 3

可能是Hashed Adapter Objects（如果你能在网上找到一个很好的解释 - 它们似乎缺乏。）

Answer 4

刚刚离开顶部：

我喜欢接受的答案中关于只有一个带有属性地图的类的建议。我也认为behvavior也可以这样组装：

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 5

我不确定我是否正确理解了这个问题。我假设有一个复杂的'模型更新逻辑'。不要通过60个类分发它，将它保存在一个地方，将它从事件类中移出（Mediator模式，类型）。

你的调解员将使用事件类（我不知道你怎么能在这里使用Flyweight），事件可以解析自己。

如果更新规则非常复杂，则无法使用通用编程语言解决问题。考虑使用基于规则的引擎或类似的东西。

适当的事件日志解析器设计模式？

5 个答案: