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

Question

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

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

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

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

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

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

Answer 1

好吧...一方面，而不是具有所有属性联合的单个事件类，或 61 个事件类(1 个基础，60 个子)，在变化如此之大的场景中，我很想有一个事件类，它使用属性包(字典、哈希表、w/e 漂浮你的船)来存储事件信息。事件的类型只是放入包中的另一个属性值。我倾向于那样做的主要原因只是因为我不愿意维护任何东西的 60 个派生类。

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

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