事件日志分析器的适当设计模式?

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

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

因此,我尝试了一个非常丑陋的命令式解析器,它逐行遍历日志,然后逐行处理事件。然后我尝试了一个使用“nextEvent”模式的词汇规范,该模式在循环中调用并进行处理。然后我尝试了一个普通的老“parse”方法,它从不返回,只向注册的侦听器回调触发事件。我尝试了不管事件类型如何的单个回调,以及针对每个事件类型的特定回调方法。

我尝试了一个包含所有可能属性的联合的基本“事件”类。我试图避免“new event”调用(因为可能会有大量的事件,并且事件对象通常是短期的),并使用带有基元属性参数的每种类型的回调方法。我尝试为60个事件类型中的每一个都有一个子类,其中一个抽象事件父类具有7个公共基属性。

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

问题是,模型更新逻辑中有很多是共享的,其中有很多是特定于子类的,我开始对整个过程感到困惑。我希望有人至少能指点我一个可以考虑的方向!