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

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

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

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

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

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

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