7

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

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

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

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

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

问题是很多模型更新逻辑是共享的，其中很多是特定于子类的，我刚刚开始对整个事情感到困惑。我希望有人至少可以指出我考虑的方向！

4

5 回答 5

3

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

最大的问题是......在处理事件时，您与事件有什么关系。您是否将它们格式化成报告，将它们组织成数据库表，如果发生某些事件时唤醒人们......什么？

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

于 2008-09-18T16:34:19.070 回答
2

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

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

于 2008-09-18T16:34:13.203 回答
1

可能是散列适配器对象（如果你能在网上找到一个很好的解释——它们似乎缺乏。）

于 2008-09-18T16:34:10.100 回答
1

就在顶部：

我喜欢接受的答案中关于只有一个具有属性映射的类的建议。我也认为行为也可以这样组装：

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。给你，有一个模式名称给你！

于 2008-10-20T21:29:41.090 回答
0

我不确定我是否正确理解了这个问题。我假设有一个复杂的“模型更新逻辑”。不要将其分配到 60 个类中，将其保存在一个地方，将其从事件类中移出（类似于中介者模式）。

您的 Mediator 将使用事件类（我不知道您如何在这里使用享元），事件可以自己解析。

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

于 2008-09-18T19:56:37.147 回答